<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><title>FindBugs Bug Descriptions</title>
<link rel="stylesheet" type="text/css" href="findbugs.css"/>
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon"/>
</head><body>

<table width="100%"><tr>

<td bgcolor="#b9b9fe" valign="top" align="left" width="20%"> 
<table width="100%" cellspacing="0" border="0"> 
<tr><td><a class="sidebar" href="index.html"><img src="umdFindbugs.png" alt="FindBugs"></a></td></tr> 

<tr><td>&nbsp;</td></tr>

<tr><td><b>Docs and Info</b></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="findbugs2.html">FindBugs 2.0</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="demo.html">Demo and data</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="users.html">Users and supporters</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="http://findbugs.blogspot.com/">FindBugs blog</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="factSheet.html">Fact sheet</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="manual/index.html">Manual</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="ja/manual/index.html">Manual(ja/&#26085;&#26412;&#35486;)</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="FAQ.html">FAQ</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="bugDescriptions.html">Bug descriptions</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="bugDescriptions_ja.html">Bug descriptions(ja/&#26085;&#26412;&#35486;)</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="bugDescriptions_fr.html">Bug descriptions(fr)</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="mailingLists.html">Mailing lists</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="publications.html">Documents and Publications</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="links.html">Links</a></font></td></tr> 

<tr><td>&nbsp;</td></tr>

<tr><td><a class="sidebar" href="downloads.html"><b>Downloads</b></a></td></tr> 

<tr><td>&nbsp;</td></tr>

<tr><td><a class="sidebar" href="http://www.cafeshops.com/findbugs"><b>FindBugs Swag</b></a></td></tr>

<tr><td>&nbsp;</td></tr>

<tr><td><b>Development</b></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="http://sourceforge.net/tracker/?group_id=96405">Open bugs</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="reportingBugs.html">Reporting bugs</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="contributing.html">Contributing</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="team.html">Dev team</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="api/index.html">API</a> <a class="sidebar" href="api/overview-summary.html">[no frames]</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="Changes.html">Change log</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="http://sourceforge.net/projects/findbugs">SF project page</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="http://code.google.com/p/findbugs/source/browse/">Browse source</a></font></td></tr> 
<tr><td><font size="-1">&nbsp;<a class="sidebar" href="http://code.google.com/p/findbugs/source/list">Latest code changes</a></font></td></tr> 
</table> 
</td>
<td align="left" valign="top">
<h1>FindBugs Bug Descriptions</h1>
<p>This document lists the standard bug patterns reported by
<a href="http://findbugs.sourceforge.net">FindBugs</a> version 3.0.0.</p>
<h2>Summary</h2>
<table width="100%">
<tr bgcolor="#b9b9fe"><th>Description</th><th>Category</th></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS">BC: equals メソッドは引数の型を仮定するべきではない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BIT_SIGNED_CHECK">BIT: ビット演算の符号をチェックする</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#CN_IDIOM">CN: Cloneable を実装したクラスが clone メソッドを定義していないか、使用していない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CN_IDIOM_NO_SUPER_CALL">CN: clone メソッドが super.clone() を呼び出していない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE">CN: Cloneable を実装していないクラスが clone メソッドを定義している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CNT_ROUGH_CONSTANT_VALUE">CNT: 既知の定数の雑な値を見つける</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#CO_ABSTRACT_SELF">Co: 抽象クラスは共変な compareTo メソッドを定義している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CO_SELF_NO_OBJECT">Co: 共変な compareTo メソッドの定義</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DE_MIGHT_DROP">DE: 例外を捨てているかもしれないメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DE_MIGHT_IGNORE">DE: 例外を無視しているかもしれないメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS">DMI: エントリセットの要素を加えることは、Entry オブジェクトの再利用のために失敗するかもしれない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_RANDOM_USED_ONLY_ONCE">DMI: Random オブジェクトが作成され1度しか使われない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION">DMI: コレクションを消去するために removeAll メソッドを使用しない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_EXIT">Dm: System.exit(...) を呼び出しているメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_RUN_FINALIZERS_ON_EXIT">Dm: 危険なメソッド runFinalizersOnExit を呼び出しているメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: String パラメータを == や != を使用して比較している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ES_COMPARING_STRINGS_WITH_EQ">ES: String オブジェクトを == や != を使用して比較している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_ABSTRACT_SELF">Eq: 抽象クラスは共変な equals メソッドを宣言している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS">Eq: equals メソッドは互換性のないオペランドをチェックしている</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_COMPARETO_USE_OBJECT_EQUALS">Eq: compareTo(...) メソッドを定義して Object.equals() を使用しているクラス</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_GETCLASS_AND_CLASS_CONSTANT">Eq: equals メソッドはサブタイプのために失敗する</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_SELF_NO_OBJECT">Eq: 共変な equals メソッドの定義</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_EMPTY">FI: 空のファイナライザは削除するべき</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#FI_EXPLICIT_INVOCATION">FI: ファイナライザの明示的な呼び出し</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_FINALIZER_NULLS_FIELDS">FI: ファイナライザはフィールドを null にする</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#FI_FINALIZER_ONLY_NULLS_FIELDS">FI: ファイナライザはフィールドを null にするだけ</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_MISSING_SUPER_CALL">FI: ファイナライザはスーパークラスのファイナライザを呼び出していない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#FI_NULLIFY_SUPER">FI: ファイナライザはスーパークラスのファイナライザを無効にしている</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_USELESS">FI: ファイナライザはスーパークラスのファイナライザを呼び出しているだけ</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_USES_NEWLINE">FS: 書式文字列は \n よりも %n を使用するべき</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#GC_UNCHECKED_TYPE_IN_GENERIC_CALL">GC: 検査されない型への総称呼び出し</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_EQUALS_NO_HASHCODE">HE: equals メソッドは定義していますが hashCode メソッドは定義していないクラス</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#HE_EQUALS_USE_HASHCODE">HE: equals メソッドを定義して Object.hashCode() を使用しているクラス</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_HASHCODE_NO_EQUALS">HE: hashCode メソッドを定義していますが equals メソッドは定義していないクラス</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#HE_HASHCODE_USE_OBJECT_EQUALS">HE: hashCode メソッドを定義して Object.equals() を使用しているクラス</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_INHERITS_EQUALS_USE_HASHCODE">HE: equals メソッドを継承して Object.hashCode() を使用しているクラス</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">IC: スーパークラスは初期化中にサブクラスを使用している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IMSE_DONT_CATCH_IMSE">IMSE: 疑わしい IllegalMonitorStateException のキャッチ</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ISC_INSTANTIATE_STATIC_CLASS">ISC: static メソッドだけを提供するクラスの不必要なインスタンス化</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IT_NO_SUCH_ELEMENT">It: Iterator.next() が NoSuchElementException をスローできない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION">J2EE: HttpSession への非直列化可能オブジェクトの格納</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">JCIP: 不変クラスのフィールドは final にすべき</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_BOOLEAN_RETURN_NULL">NP: 戻り型が Boolean のメソッドが明示的に null を返している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_CLONE_COULD_RETURN_NULL">NP: null を返すかもしれない clone メソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT">NP: equals メソッドは null の引数をチェックしていない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_TOSTRING_COULD_RETURN_NULL">NP: null を返すかもしれない toString メソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_CLASS_NAMING_CONVENTION">Nm: クラス名は大文字から始めるべき</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_CLASS_NOT_EXCEPTION">Nm: 例外クラスのように命名されているが、クラスは Exception から派生されていない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_CONFUSING">Nm: 紛らわしい名前のメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_FIELD_NAMING_CONVENTION">Nm: フィールド名は小文字から始めるべき</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER">Nm: Java の後のバージョンのキーワードである識別子を使用している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER">Nm: Java の後のバージョンのキーワードである識別子を使用している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_METHOD_NAMING_CONVENTION">Nm: メソッド名は小文字から始めるべきです</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_SAME_SIMPLE_NAME_AS_INTERFACE">Nm: クラス名は実装されたインタフェースの単純名を遮るべきではない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_SAME_SIMPLE_NAME_AS_SUPERCLASS">Nm: クラス名はスーパークラスの単純名を遮るべきではない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_VERY_CONFUSING_INTENTIONAL">Nm: 非常に紛らわしい名前のメソッド (多分意図的)</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_WRONG_PACKAGE_INTENTIONAL">Nm: パラメータの間違ったパッケージのためにスーパークラスのメソッドをオーバーライドしていないメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ODR_OPEN_DATABASE_RESOURCE">ODR: データベースリソースのクローズに失敗するかもしれないメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH">ODR: 例外経路でデータベースリソースのクローズに失敗するかもしれないメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#OS_OPEN_STREAM">OS: ストリームのクローズに失敗するかもしれないメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#OS_OPEN_STREAM_EXCEPTION_PATH">OS: 例外経路でストリームのクローズに失敗するかもしれないメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS">PZ: 繰り返しでエントリオブジェクトを再利用しない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RC_REF_COMPARISON_BAD_PRACTICE">RC: 定数への疑わしい参照比較</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN">RC: Boolean 値の疑わしい参照比較</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RR_NOT_CHECKED">RR: InputStream.read() の戻り値を無視しているメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SR_NOT_CHECKED">RR: InputStream.skip() の戻り値を無視しているメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_NEGATING_RESULT_OF_COMPARETO">RV: compareTo()/compare() の結果を無効にする</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">RV: 例外的戻り値を無視しているメソッド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SI_INSTANCE_BEFORE_FINALS_ASSIGNED">SI: スタティックイニシャライザは、すべての static final フィールドが代入される前にインスタンスを作成する</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SW_SWING_METHODS_INVOKED_IN_SWING_THREAD">SW: Swing メソッドは AWT イベントディスパッチスレッドから呼び出す必要がある</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_BAD_FIELD">Se: 直列化可能クラスの非 transient で非直列化可能なインスタンスフィールド</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_BAD_FIELD_INNER_CLASS">Se: 非直列化可能クラスに直列化可能な内部クラスがある</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_BAD_FIELD_STORE">Se: 非直列化可能な値を直列化可能クラスのインスタンスフィールドに格納している</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator は Serializable を実装していない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_INNER_CLASS">Se: 直列化可能な内部クラス</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID が final ではない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID が long ではない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID が static ではない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_NO_SUITABLE_CONSTRUCTOR">Se: Serializable なクラスのスーパークラスで、引数なしコンストラクタを定義していない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION">Se: Externalizable なクラスが引数なしコンストラクタを定義していない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: readResolve メソッドの戻り値の型が Object で宣言されていない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_TRANSIENT_FIELD_NOT_RESTORED">Se: 直列化復元によって設定されない transient フィールド </a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_NO_SERIALVERSIONID">SnVI: Serializable なクラスが serialVersionUID を定義していない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UI_INHERITANCE_UNSAFE_GETRESOURCE">UI: クラスが拡張されるなら getResource の使い方は安全ではないかもしれない</a></td><td>Bad practice</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_IMPOSSIBLE_CAST">BC: 不可能なキャスト</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_IMPOSSIBLE_DOWNCAST">BC: 不可能なダウンキャスト</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY">BC: toArray メソッドの結果の不可能なダウンキャスト</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_IMPOSSIBLE_INSTANCEOF">BC: 常に false を返す instanceof</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BIT_ADD_OF_SIGNED_BYTE">BIT: 符号付きバイト値のビット加算</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BIT_AND">BIT: 互換性のないビットマスク</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BIT_AND_ZZ">BIT: ((...) & 0) == 0 なのか確かめている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BIT_IOR">BIT: 互換性のないビットマスク</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BIT_IOR_OF_SIGNED_BYTE">BIT: 符号付きバイト値のビット論理和</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BIT_SIGNED_CHECK_HIGH_BIT">BIT: ビット演算の符号をチェックする</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BOA_BADLY_OVERRIDDEN_ADAPTER">BOA: スーパークラスの Adapter で実装されるメソッドを誤ってオーバーライドしているクラス</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ICAST_BAD_SHIFT_AMOUNT">BSHIFT: 32ビット int の-31から31の範囲を超えた量によるシフト</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR">Bx: プリミティブ値が3項演算子のためにアンボクシングされて、型変換される</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CO_COMPARETO_RESULTS_MIN_VALUE">Co: compareTo()/compare() は Integer.MIN_VALUE を返す</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_LOCAL_INCREMENT_IN_RETURN">DLS: return 文に役に立たないインクリメントがある</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_STORE_OF_CLASS_LITERAL">DLS: クラスリテラルの無効な代入</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DLS_OVERWRITTEN_INCREMENT">DLS: 上書きされたインクリメント</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_ARGUMENTS_WRONG_ORDER">DMI: 逆にされた引数</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_BAD_MONTH">DMI: 月のための間違った定数値</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE">DMI: 正確に表されない double から構築された BigDecimal</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext メソッドで next メソッドを呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES">DMI: コレクションは自分自身を含めるべきではない</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_DOH">DMI: D'oh! 無意味なメソッド呼び出し</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_INVOKING_HASHCODE_ON_ARRAY">DMI: 配列で hashCode メソッドを呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT">DMI: int に対して Double.longBitsToDouble() を呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_VACUOUS_SELF_COLLECTION_CALL">DMI: コレクションへの無意味な呼び出し</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION">Dm: ランタイムリテンションなしで、アノテーションの存在を調べるためにリフレクションを使用することはできない</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR">Dm: ScheduledThreadPoolExecutor の最大プールサイズを変えようとする無駄な試み</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS">Dm: コアプールサイズが0の ScheduledThreadPoolExecutor の作成</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD">Dm: EasyMock メソッドへの役に立たない/無意味な呼び出し</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EC_ARRAY_AND_NONARRAY">EC: equals メソッドを使用して配列と非配列を比較している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EC_BAD_ARRAY_COMPARE">EC: 配列の equals メソッド呼び出しは == と等価である</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EC_INCOMPATIBLE_ARRAY_COMPARE">EC: equals(...) メソッドを使用して互換性のない配列を比較している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EC_NULL_ARG">EC: equals(null) の呼び出し</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EC_UNRELATED_CLASS_AND_INTERFACE">EC: equals メソッドを呼び出して無関係のクラスとインタフェースを比較している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_INTERFACES">EC: equals メソッドを呼び出して異なる型のインタフェースを比較している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EC_UNRELATED_TYPES">EC: equals メソッドを呼び出して異なる型を比較している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EC_UNRELATED_TYPES_USING_POINTER_EQUALITY">EC: 参照等価性を使用して異なる型を比較している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_ALWAYS_FALSE">Eq: equals メソッドは常に false を戻す</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_ALWAYS_TRUE">Eq: equals メソッドは常に true を返す</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_COMPARING_CLASS_NAMES">Eq: equals メソッドはクラスオブジェクトではなくクラス名を比較している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_DONT_DEFINE_EQUALS_FOR_ENUM">Eq: 列挙型は共変な equals メソッドを定義している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_OTHER_NO_OBJECT">Eq: equals(Object) メソッドをオーバーライドしていない equals メソッドの定義</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_OTHER_USE_OBJECT">Eq: Object.equals(Object) をオーバーライドしていない equals メソッドの定義</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC">Eq: equals メソッドはスーパークラスの equals メソッドをオーバーライドしているが、対称的ではないかもしれない</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_SELF_USE_OBJECT">Eq: 共変な equals メソッドを定義して、Object.equals(Object) を継承している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER">FE: NaN への等価性のための絶望的なテスト</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_BAD_ARGUMENT">FS: 書式指示子へ渡している引数に互換性がない</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_BAD_CONVERSION">FS: 与えられた引数の型は書式指示子に合致しません</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED">FS: printf スタイルの書式が期待されているところで MessageFormat が与えられている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED">FS: 書式文字列で実際に使われるより、多くの引数が渡されている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_ILLEGAL">FS: 無効な書式文字列</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#VA_FORMAT_STRING_MISSING_ARGUMENT">FS: 書式文字列は足りない引数を参照している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT">FS: 書式文字列ための前の引数がない</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#GC_UNRELATED_TYPES">GC: 型パラメータとメソッド引数に関係がない</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS">HE: ハッシュ化された文脈でハッシュ化できないクラスの使用がシグネチャで宣言されている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#HE_USE_OF_UNHASHABLE_CLASS">HE: ハッシュデータ構造で hashCode メソッドのないクラスを使用している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ICAST_INT_2_LONG_AS_INSTANT">ICAST: int 値を long に変換して絶対時間として使用している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL">ICAST: 整数値を double にキャストして Math.ceil() に渡している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND">ICAST: 整数値を float にキャストして Math.round() に渡している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD">IJU: run メソッドでの JUnit アサーションは JUnit によって通知されない</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IJU_BAD_SUITE_METHOD">IJU: TestCase は suite メソッドの間違った宣言をしている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IJU_NO_TESTS">IJU: TestCase はテストがない </a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IJU_SETUP_NO_SUPER">IJU: TestCase は super.setup() を呼び出さない setUp メソッドを実装している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IJU_SUITE_NOT_STATIC">IJU: TestCase は 非 static な suite メソッドを実装している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IJU_TEARDOWN_NO_SUPER">IJU: TestCase は super.tearDown() を呼び出さない tearDown メソッドを実装している </a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IL_CONTAINER_ADDED_TO_ITSELF">IL: コレクションは自分自身を追加している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IL_INFINITE_LOOP">IL: 明らかな無限ループ</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IL_INFINITE_RECURSIVE_LOOP">IL: 明らかな無限再帰ループ</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IM_MULTIPLYING_RESULT_OF_IREM">IM: 整数剰余の結果の整数乗算</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#INT_BAD_COMPARISON_WITH_INT_VALUE">INT: int 値と long 定数との間違った比較</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE">INT: 負でない値と負の定数との間違った比較</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: 符号付きバイトの間違った比較</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IO_APPENDING_TO_OBJECT_OUTPUT_STREAM">IO: オブジェクト出力ストリームへの追加は失敗に終わる</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN">IP: メソッドで読み取られずに上書きされているパラメータ</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MF_CLASS_MASKS_FIELD">MF: スーパークラスのフィールドを隠すフィールドを定義しているクラス</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MF_METHOD_MASKS_FIELD">MF: フィールドを隠す変数を定義しているメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_ALWAYS_NULL">NP: null 値を利用している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_ALWAYS_NULL_EXCEPTION">NP: null 値を例外経路で利用している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_ARGUMENT_MIGHT_BE_NULL">NP: null の引数をチェックしていないメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_CLOSING_NULL">NP: 常に null 値のオブジェクトで close メソッドを呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_GUARANTEED_DEREF">NP: null 値を利用することが保証されている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH">NP: null 値を例外経路で利用することが保証されている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">NP: 非 null フィールドは初期化されていない</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NONNULL_PARAM_VIOLATION">NP: メソッド呼び出しは非 null パラメータに対して null を渡している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NONNULL_RETURN_VIOLATION">NP: null を返すかもしれないメソッドが @NonNull 宣言されている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NULL_INSTANCEOF">NP: null とわかっている値をその型のインスタンスなのか確かめている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_ON_SOME_PATH">NP: null 値を利用している可能性がある</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NULL_ON_SOME_PATH_EXCEPTION">NP: null 値を例外経路で利用している可能性がある</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_PARAM_DEREF">NP: メソッド呼び出しは非 null パラメータに対して null を渡している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS">NP: メソッド呼び出しは非 null パラメータに対して null を渡している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_PARAM_DEREF_NONVIRTUAL">NP: 非 null パラメータに null を渡している非仮想メソッドの呼び出し</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_OPTIONAL_RETURN_NULL">NP: Optional の戻り型を持つメソッドが明示的に null を返す</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_STORE_INTO_NONNULL_FIELD">NP: @NonNull でアノテートされたフィールドに null を格納している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_UNWRITTEN_FIELD">NP: 書き込まれていないフィールドの読み出し</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_BAD_EQUAL">Nm: クラスは equal(Object) を定義しています。equals(Object) にすべきですか?</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_LCASE_HASHCODE">Nm: クラスは hashcode() を定義しています。hashCode() にすべきですか?</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_LCASE_TOSTRING">Nm: クラスは tostring() を定義しています。toString() にすべきですか?</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: 明らかなメソッドとコンストラクタの混乱</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NM_VERY_CONFUSING">Nm: 非常に紛らわしい名前のメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NM_WRONG_PACKAGE">Nm: パラメータの間違ったパッケージのために、スーパークラスのメソッドをオーバーライドしていないメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: 論理式で boolean リテラル値を代入しているメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RC_REF_COMPARISON">RC: 疑わしい参照比較</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE">RCN: すでに利用していた値の null チェック</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: 正規表現のための無効な構文</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION">RE: 正規表現のために使われている File.separator</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RE_POSSIBLE_UNINTENDED_PATTERN">RE: 正規表現のために使われている "." または "|"</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_01_TO_INT">RV: 0から1の乱数値は整数値0に丸められる</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_ABSOLUTE_VALUE_OF_HASHCODE">RV: 符号付き32ビットハッシュコードの絶対値を計算する間違った試み</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_ABSOLUTE_VALUE_OF_RANDOM_INT">RV: 符号付き整数の乱数の絶対値を計算する間違った試み</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE">RV: compareTo によって返された特定の値のコードチェック</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_EXCEPTION_NOT_THROWN">RV: 作成した例外をスローするのではなく捨てている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_IGNORED">RV: 戻り値を無視しているメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RpC_REPEATED_CONDITIONAL_TEST">RpC: 条件テストの繰り返し</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_FIELD_SELF_ASSIGNMENT">SA: フィールドの自己代入</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_FIELD_SELF_COMPARISON">SA: フィールドとそれ自身との自己比較</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_FIELD_SELF_COMPUTATION">SA: フィールドの無意味な自己演算 (たとえば、 x & x)</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_ASSIGNMENT_INSTEAD_OF_FIELD">SA: フィールドへの代入ではなくローカル変数への自己代入</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_LOCAL_SELF_COMPARISON">SA: ローカル変数とそれ自身との自己比較</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_COMPUTATION">SA: 変数の無意味な自己演算 (たとえば、x & x)</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH">SF: switch 文のフォールスルーのために格納が無効になっている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW">SF: スローする switch 文のフォールスルーのために格納が無効になっている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SIC_THREADLOCAL_DEADLY_EMBRACE">SIC: 非 static 内部クラスとスレッドローカルのデッドロック</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SIO_SUPERFLUOUS_INSTANCEOF">SIO: instanceof 演算子を使用した不必要な型チェック</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SQL_BAD_PREPARED_STATEMENT_ACCESS">SQL: インデックスが0で PreparedStatement にアクセスしようとしているメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SQL_BAD_RESULTSET_ACCESS">SQL: インデックスが0で ResultSet にアクセスしようとしているメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#STI_INTERRUPTED_ON_CURRENTTHREAD">STI: interrupted メソッドを呼び出すために不要な currentThread メソッドを呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#STI_INTERRUPTED_ON_UNKNOWNTHREAD">STI: スレッドインスタンスで static Thread.interrupted() を呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_METHOD_MUST_BE_PRIVATE">Se: 直列化機構のために private にしなければならないメソッド</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_READ_RESOLVE_IS_STATIC">Se: readResolve メソッドが static メソッドとして宣言されている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED">TQ: 型修飾子でアノテーションされた値がその修飾子を付けてはならない値を必要とする場所で使われている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#TQ_COMPARING_VALUES_WITH_INCOMPATIBLE_TYPE_QUALIFIERS">TQ: 互換性のない型修飾子による比較値</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: 型修飾子を付けていないかもしれない値がその型修飾子を必要とする方法で常に使われている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: 型修飾子を付けているかもしれない値がその型修飾子を禁止する方法で常に使われている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED">TQ: 型修飾子でアノテートされていない値がその修飾子が付けられた値を必要とする場所で使われている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#TQ_UNKNOWN_VALUE_USED_WHERE_ALWAYS_STRICTLY_REQUIRED">TQ: 型修飾子がない値が修飾子を必要とする場所で使われている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: 呼び出し不可能なメソッドが無名クラスで定義されている</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UR_UNINIT_READ">UR: コンストラクタで初期化されていないフィールドを読み出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR">UR: スーパークラスのコンストラクタから呼び出されるメソッドで初期化されていないフィールドを読み出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY">USELESS_STRING: 名前のない配列で toString メソッドを呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_INVOKING_TOSTRING_ON_ARRAY">USELESS_STRING: 配列で toString メソッドを呼び出している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_BAD_CONVERSION_FROM_ARRAY">USELESS_STRING: 書式文字列を使用して役に立たない方法で配列をフォーマットしている</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UWF_NULL_FIELD">UwF: null に設定されるだけのフィールド</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UWF_UNWRITTEN_FIELD">UwF: 書き込まれていないフィールド</a></td><td>Correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG">VA: 可変長引数を期待しているメソッドにプリミティブ型の配列を渡している</a></td><td>Correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE">LG: ロガーの変更は OpenJDK の弱参照が原因で潜在的に失われる</a></td><td>Experimental</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#OBL_UNSATISFIED_OBLIGATION">OBL: ストリームやリソースのクリーンアップに失敗するかもしれないメソッド</a></td><td>Experimental</td></tr>
<tr bgcolor="#ffffff"><td><a href="#OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE">OBL: チェック例外でストリームやリソースのクリーンアップに失敗するかもしれないメソッド</a></td><td>Experimental</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_CONVERT_CASE">Dm: 呼び出したメソッドの Locale パラメータの使用を検討する</a></td><td>Internationalization</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_DEFAULT_ENCODING">Dm: デフォルトエンコーディングへの依存</a></td><td>Internationalization</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED">DP: doPrivileged ブロック内で作成されるべきクラスローダ</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DP_DO_INSIDE_DO_PRIVILEGED">DP: doPrivileged ブロック内で呼び出すべきメソッド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EI_EXPOSE_REP">EI: 可変オブジェクトへの参照を返すことによって内部表現を暴露するかもしれないメソッド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EI_EXPOSE_REP2">EI2: 可変オブジェクトへの参照を取り込むことによって内部表現を暴露するかもしれないメソッド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FI_PUBLIC_SHOULD_BE_PROTECTED">FI: ファイナライザは public ではなく protected にすべき</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EI_EXPOSE_STATIC_REP2">MS: static フィールドに可変オブジェクトを格納することによって、内部の静的状態を暴露するかもしれないメソッド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_CANNOT_BE_FINAL">MS: final でないフィールドは悪質なコードから保護できない</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_EXPOSE_REP">MS: 配列を返すことによって内部表現を暴露するかもしれない public static メソッド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_FINAL_PKGPROTECT">MS: final かつパッケージプロテクテッドにすべきフィールド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_MUTABLE_ARRAY">MS: 可変配列のフィールド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_MUTABLE_HASHTABLE">MS: 可変 Hashtable のフィールド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_OOI_PKGPROTECT">MS: インタフェースから移動してパッケージプロテクテッドにすべきフィールド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_PKGPROTECT">MS: パッケージプロテクテッドにすべきフィールド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MS_SHOULD_BE_FINAL">MS: final にすべきフィールド</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MS_SHOULD_BE_REFACTORED_TO_BE_FINAL">MS: final でないフィールドはリファクタリングするべき</a></td><td>Malicious code vulnerability</td></tr>
<tr bgcolor="#ffffff"><td><a href="#AT_OPERATION_SEQUENCE_ON_CONCURRENT_ABSTRACTION">AT: 並行抽象の呼び出しシーケンスはアトミックではないかもしれない</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DC_DOUBLECHECK">DC: フィールドのダブルチェックの可能性</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DL_SYNCHRONIZATION_ON_BOOLEAN">DL: Boolean の同期化</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE">DL: デッドロックの原因になる可能性があるボクシングされたプリミティブ型の同期化</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DL_SYNCHRONIZATION_ON_SHARED_CONSTANT">DL: 正準化した文字列の同期化</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE">DL: ボクシングされたプリミティブ値の同期化</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_MONITOR_WAIT_ON_CONDITION">Dm: Condition で wait メソッドを呼び出している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_USELESS_THREAD">Dm: デフォルトの空の run メソッドを使用して作成されたスレッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ESync_EMPTY_SYNC">ESync: 空の synchronized ブロック</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IS2_INCONSISTENT_SYNC">IS: 一貫性のない同期化</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IS_FIELD_NOT_GUARDED">IS: 並行アクセスに対してガードされていないフィールド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#JLM_JSR166_LOCK_MONITORENTER">JLM: Lock で同期化している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#JLM_JSR166_UTILCONCURRENT_MONITORENTER">JLM: java.util.concurrent のインスタンスで同期化している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#JML_JSR166_CALLING_WAIT_RATHER_THAN_AWAIT">JLM: util.concurrent 抽象でモニタスタイルの wait メソッドを使用している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#LI_LAZY_INIT_STATIC">LI: static フィールドの間違った遅延初期化</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#LI_LAZY_INIT_UPDATE_STATIC">LI: 更新される static フィールドの間違った遅延初期化</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ML_SYNC_ON_FIELD_TO_GUARD_CHANGING_THAT_FIELD">ML: フィールドを同期化でガードしようとする無駄な試み</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ML_SYNC_ON_UPDATED_FIELD">ML: 更新されるフィールドで同期化しているメソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MSF_MUTABLE_SERVLET_FIELD">MSF: 可変サーブレットフィールド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MWN_MISMATCHED_NOTIFY">MWN: 不整合な notify メソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MWN_MISMATCHED_WAIT">MWN: 不整合な wait メソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NN_NAKED_NOTIFY">NN: 裸の notify メソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_SYNC_AND_NULL_CHECK_FIELD">NP: 同じフィールドでの同期化と null チェック</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NO_NOTIFY_NOT_NOTIFYALL">No: notifyAll メソッドではなく notify メソッドを使用している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RS_READOBJECT_SYNC">RS: readObject メソッドを同期化しているクラス</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED">RV: putIfAbsent の戻り値は無視されて putIfAbsent に渡した値は再利用された</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RU_INVOKE_RUN">Ru: スレッドで run メソッドを呼び出している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SC_START_IN_CTOR">SC: Thread.start() を呼び出しているコンストラクタ</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SP_SPIN_ON_FIELD">SP: スピンロックをしているメソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: static Calendar の呼び出し</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: static DateFormat の呼び出し</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#STCAL_STATIC_CALENDAR_INSTANCE">STCAL: static Calendar フィールド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE">STCAL: static DateFormat</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SWL_SLEEP_WITH_LOCK_HELD">SWL: ロックを保持して Thread.sleep() を呼び出しているメソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#TLW_TWO_LOCK_WAIT">TLW: 2つ以上のロックを保持して wait メソッドを呼び出している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UG_SYNC_SET_UNSYNC_GET">UG: 同期化していない get メソッド、同期化している set メソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UL_UNRELEASED_LOCK">UL: すべての経路でロックが解除されないメソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UL_UNRELEASED_LOCK_EXCEPTION_PATH">UL: すべての例外経路でロックが解除されないメソッド</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UW_UNCOND_WAIT">UW: wait メソッドの無条件呼び出し</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#VO_VOLATILE_INCREMENT">VO: volatile フィールドへのインクリメントはアトミックではない</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VO_VOLATILE_REFERENCE_TO_ARRAY">VO: 配列への volatile 参照は、配列要素を volatile として扱わない</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL">WL: クラスリテラルではなく getClass で同期化している</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#WS_WRITEOBJECT_SYNC">WS: writeObject メソッドは同期化しているがその他のメソッドは同期化していないクラス</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() がループの中にない</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#ffffff"><td><a href="#WA_NOT_IN_LOOP">Wa: wait メソッドがループの中にない</a></td><td>Multithreaded correctness</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BX_BOXING_IMMEDIATELY_UNBOXED">Bx: プリミティブ値がボクシングされて、すぐにアンボクシングされる</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION">Bx: プリミティブ値がプリミティブ型の型変換をするためにボクシングされて、アンボクシングされる</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BX_UNBOXING_IMMEDIATELY_REBOXED">Bx: ボクシングされた値がアンボクシングされて、すぐに再ボクシングされる</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_BOXED_PRIMITIVE_FOR_PARSING">Bx: ボクシング/アンボクシングはプリミティブを解析する</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_BOXED_PRIMITIVE_TOSTRING">Bx: toString メソッドを呼び出すためにプリミティブ型のラッパクラスのインスタンスを作成している</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_FP_NUMBER_CTOR">Bx: 効率が悪い浮動小数点 Number コンストラクタを呼び出しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_NUMBER_CTOR">Bx: 効率が悪い Number コンストラクタを呼び出しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_BLOCKING_METHODS_ON_URL">Dm: URL の equals メソッドと hashCode メソッドはブロックする</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_COLLECTION_OF_URLS">Dm: URL の Map や Set はひどい性能になる可能性がある</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_BOOLEAN_CTOR">Dm: 効率が悪い Boolean コンストラクタを呼び出しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_GC">Dm: 明示的なガベージコレクション</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_NEW_FOR_GETCLASS">Dm: クラスオブジェクトを得るためだけにインスタンスを作成しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_NEXTINT_VIA_NEXTDOUBLE">Dm: 整数の乱数を生成するためには nextDouble メソッド ではなく nextInt メソッドを使用する</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_STRING_CTOR">Dm: 効率が悪い new String(String) コンストラクタを呼び出しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DM_STRING_TOSTRING">Dm: String の toString メソッドを呼び出しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DM_STRING_VOID_CTOR">Dm: 効率が悪い new String() コンストラクタを呼び出しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#HSC_HUGE_SHARED_STRING_CONSTANT">HSC: 複数のクラスファイルにわたって複製されている巨大な文字列定数</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IIO_INEFFICIENT_INDEX_OF">IIO: String.indexOf(String) の非効率的な使用</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IIO_INEFFICIENT_LAST_INDEX_OF">IIO: String.lastIndexOf(String)　の非効率的な使用</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ITA_INEFFICIENT_TO_ARRAY">ITA: 長さが0の配列の引数で toArray メソッドを使用しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: ループの中で + を使用して文字列を連結しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SIC_INNER_SHOULD_BE_STATIC">SIC: static 内部クラスにすべき</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SIC_INNER_SHOULD_BE_STATIC_ANON">SIC: 名前付き static 内部クラスにリファクタリングできるかもしれない</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS">SIC: static 内部クラスにリファクタリングできるかもしれない</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SS_SHOULD_BE_STATIC">SS: 読み出されないフィールド</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UM_UNNECESSARY_MATH">UM: 定数値で Math クラスの static メソッドを呼び出しているメソッド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UPM_UNCALLED_PRIVATE_METHOD">UPM: private メソッドは決して呼び出されない</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#URF_UNREAD_FIELD">UrF: 読み出されないフィールド</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UUF_UNUSED_FIELD">UuF: 未使用のフィールド</a></td><td>Performance</td></tr>
<tr bgcolor="#ffffff"><td><a href="#WMI_WRONG_MAP_ITERATOR">WMI: entrySet イテレータではなく効率が悪い keySet イテレータを使用している</a></td><td>Performance</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_CONSTANT_DB_PASSWORD">Dm: ハードコードされた定数データベースパスワード</a></td><td>Security</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_EMPTY_DB_PASSWORD">Dm: 空のデータベースパスワード</a></td><td>Security</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#HRS_REQUEST_PARAMETER_TO_COOKIE">HRS: 信頼できない入力から形成された HTTP cookie</a></td><td>Security</td></tr>
<tr bgcolor="#ffffff"><td><a href="#HRS_REQUEST_PARAMETER_TO_HTTP_HEADER">HRS: HTTP レスポンススプリッティング脆弱性</a></td><td>Security</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#PT_ABSOLUTE_PATH_TRAVERSAL">PT: サーブレットの絶対パストラバーサル</a></td><td>Security</td></tr>
<tr bgcolor="#ffffff"><td><a href="#PT_RELATIVE_PATH_TRAVERSAL">PT: サーブレットの相対パストラバーサル</a></td><td>Security</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE">SQL: SQL の Statement の  execute メソッドに定数でない文字列を渡している</a></td><td>Security</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING">SQL: PreparedStatement が定数でない文字列から生成されている</a></td><td>Security</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#XSS_REQUEST_PARAMETER_TO_JSP_WRITER">XSS: 反射型クロスサイトスクリプティング脆弱性がある JSP</a></td><td>Security</td></tr>
<tr bgcolor="#ffffff"><td><a href="#XSS_REQUEST_PARAMETER_TO_SEND_ERROR">XSS: 反射型クロスサイトスクリプティング脆弱性がエラーページにあるサーブレット</a></td><td>Security</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER">XSS: 反射型クロスサイトスクリプティング脆弱性があるサーブレット</a></td><td>Security</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: 抽象コレクションへの疑わしいキャスト</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: 具象コレクションへの疑わしいキャスト</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_UNCONFIRMED_CAST">BC: 未チェック/未確認のキャスト</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#BC_UNCONFIRMED_CAST_OF_RETURN_VALUE">BC: メソッドからの戻り値の未チェック/未確認のキャスト</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#BC_VACUOUS_INSTANCEOF">BC: 常に true を返す instanceof</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">BSHIFT: 符号なし右シフトを short/byte にキャストしている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#CI_CONFUSED_INHERITANCE">CI: final なクラスが protected フィールドを宣言している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DB_DUPLICATE_BRANCHES">DB: 2つの分岐のために同じコードを使用しているメソッド</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DB_DUPLICATE_SWITCH_CLAUSES">DB: switch 文の2つの case のために同じコードを使用しているメソッド</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_LOCAL_STORE">DLS: ローカル変数への無効な代入</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_LOCAL_STORE_IN_RETURN">DLS: return 文に役に立たない代入がある</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DLS_DEAD_LOCAL_STORE_OF_NULL">DLS: ローカル変数への無効な null 代入</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DLS_DEAD_LOCAL_STORE_SHADOWS_FIELD">DLS: フィールドを遮るローカル変数への無効な代入</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: ハードコードされた絶対パス名への参照がある</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: ObjectOutput に書き込まれる非直列化可能オブジェクト</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#DMI_USELESS_SUBSTRING">DMI: substring(0) の呼び出しは元の値を返す</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread オブジェクトが Runnable が期待されているところに渡されている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#EQ_DOESNT_OVERRIDE_EQUALS">Eq: スーパークラスの equals メソッドをオーバーライドしていないクラス</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#EQ_UNUSUAL">Eq: 異常な equals メソッド </a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#FE_FLOATING_POINT_EQUALITY">FE: 浮動小数点の等価性のためのテスト</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN">FS: Boolean 型でない引数を ％b 書式指示子を使用してフォーマットしている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">IA: 潜在的な継承されたメソッドなのか外部のメソッドなのかあいまいなメソッドの呼び出し</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IC_INIT_CIRCULARITY">IC: 初期化が循環している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ICAST_IDIV_CAST_TO_DOUBLE">ICAST: 整数の除算の結果を double または float にキャストしている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#ICAST_INTEGER_MULTIPLY_CAST_TO_LONG">ICAST: 整数乗算の結果を long にキャストしている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: 平均の計算はオーバーフローする可能性がある</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#IM_BAD_CHECK_FOR_ODD">IM: 負数で機能しない奇数チェック</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#INT_BAD_REM_BY_1">INT: 1を法とする整数の剰余</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#INT_VACUOUS_BIT_OPERATION">INT: 整数値の無意味なビットマスク演算</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#INT_VACUOUS_COMPARISON">INT: 整数値の無意味な比較</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">MTIA: Servlet クラスを拡張したクラスでのインスタンス変数の使用</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#MTIA_SUSPECT_STRUTS_INSTANCE_FIELD">MTIA: Struts Action を拡張したクラスでのインスタンス変数の使用</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_DEREFERENCE_OF_READLINE_VALUE">NP: readLine メソッドの結果が null なのか確かめないで値を利用している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_IMMEDIATE_DEREFERENCE_OF_READLINE">NP: readLine メソッドの結果をすぐに利用している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_LOAD_OF_KNOWN_NULL_VALUE">NP: null とわかっている値のロード</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION">NP: メソッドはパラメータに nullness アノテーションを強化している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_METHOD_RETURN_RELAXING_ANNOTATION">NP: メソッドは戻り値の nullness アノテーションを緩和している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE">NP: null になっている可能性があるメソッドの戻り値を利用している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_NULL_ON_SOME_PATH_MIGHT_BE_INFEASIBLE">NP: null 値を実行不可能かもしれない分岐で利用している可能性がある</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE">NP: パラメータは  非 null でなければならないが null 可能としてアノテートされている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NP_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">NP: 書き込まれていない public または protected フィールドの読み出し</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: 潜在的な非短絡論理の危険な使用</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#NS_NON_SHORT_CIRCUIT">NS: 非短絡論理の疑わしい使用</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#PZLA_PREFER_ZERO_LENGTH_ARRAYS">PZLA: null ではなく長さが0の配列を返すことを検討する</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#QF_QUESTIONABLE_FOR_LOOP">QF: 複雑か巧妙か間違ったインクリメントの for ループ</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE">RCN: 非 null 値と null 値との冗長な比較</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">RCN: 2つの null 値の冗長な比較</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE">RCN: null でないことがわかっている値の冗長な null チェック</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE">RCN: null とわかっている値の冗長な null チェック</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#REC_CATCH_EXCEPTION">REC: 例外がスローされないのに例外をキャッチしている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RI_REDUNDANT_INTERFACES">RI: スーパークラスと同じインタフェースを実装しているクラス</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_CHECK_FOR_POSITIVE_INDEXOF">RV: String.indexOf の結果が正かどうか確かめている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_DONT_JUST_NULL_CHECK_READLINE">RV: readLine メソッドの結果を null でないのか確かめた後で捨てている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_REM_OF_HASHCODE">RV: ハッシュコードの剰余は負かもしれない</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#RV_REM_OF_RANDOM_INT">RV: 符号付き32ビット整数の乱数の剰余</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#RV_RETURN_VALUE_IGNORED_INFERRED">RV: メソッドは戻り値を無視しています、これは間違いではないですか?</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_FIELD_DOUBLE_ASSIGNMENT">SA: フィールドの二重代入</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SA_LOCAL_DOUBLE_ASSIGNMENT">SA: ローカル変数の二重代入</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SA_LOCAL_SELF_ASSIGNMENT">SA: ローカル変数の自己代入</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SF_SWITCH_FALLTHROUGH">SF: 1つの case が次の case へと通り抜ける switch 文を発見した</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SF_SWITCH_NO_DEFAULT">SF: default がない switch 文を発見した</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD">ST: インスタンスメソッドから static フィールドへの書き込み</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#SE_PRIVATE_READ_RESOLVE_NOT_INHERITED">Se: サブクラスで継承できない private な readResolve メソッド</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#SE_TRANSIENT_FIELD_OF_NONSERIALIZABLE_CLASS">Se: Serializable でないクラスの transient フィールド</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: 値は型修飾子を必要としているが、不明としてマークされている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: 値は型修飾子を必要としないが、不明としてマークされている</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UCF_USELESS_CONTROL_FLOW">UCF: 役に立たない制御フロー</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: 次の行へ続くだけの役に立たない制御フロー</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD">UrF: 読み出されない public または protected フィールド</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD">UuF: 未使用の public または protected フィールド</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: コンストラクタで初期化されていないフィールドを null チェックなしで null 値を利用している</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#eeeeee"><td><a href="#UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">UwF: 書き込まてれいない public または protected フィールド</a></td><td>Dodgy code</td></tr>
<tr bgcolor="#ffffff"><td><a href="#XFB_XML_FACTORY_BYPASS">XFB: XMLインタフェースの特定の実装のインスタンスを作成しているメソッド</a></td><td>Dodgy code</td></tr>
</table>
<h2>Descriptions</h2>
<h3><a name="BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS">BC: equals メソッドは引数の型を仮定するべきではない (BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS)</a></h3>


<p>
<code>equals(Object o)</code> メソッドは、<code>o</code> の型についてどんな仮定もするべきではありません。
<code>o</code> が <code>this</code> と同じ型でないなら単に false を返すべきです。
</p>

    
<h3><a name="BIT_SIGNED_CHECK">BIT: ビット演算の符号をチェックする (BIT_SIGNED_CHECK)</a></h3>


<p>
このメソッドは、<code>((event.detail &amp; SWT.SELECTED) &gt; 0)</code> のような式を比較しています。
ビット演算をより大きい演算子で比較することは、予想外の結果 (もちろん、<code>SWT.SELECTED</code> の値による) の原因になる可能性があります。
<code>SWT.SELECTED</code> が負数であるなら、これはバグの候補です。
<code>SWT.SELECTED</code> が負ではないとしても、'&gt; 0' の代わりに '!= 0' を使うことは良いプラクティスと思われます。
</p>
<p>
Boris Bokowski
</p>

    
<h3><a name="CN_IDIOM">CN: Cloneable を実装したクラスが clone メソッドを定義していないか、使用していない (CN_IDIOM)</a></h3>


<p>
このクラスは、<code>Cloneable</code> を実装していますが、<code>clone</code> メソッドを定義していないか使用していません。
</p>

    
<h3><a name="CN_IDIOM_NO_SUPER_CALL">CN: clone メソッドが super.clone() を呼び出していない (CN_IDIOM_NO_SUPER_CALL)</a></h3>


<p>
この非 final クラスは、<code>super.clone()</code> を呼び出さない <code>clone</code> メソッドを定義しています。
クラス <i>A</i> がサブクラス <i>B</i> によって拡張され、サブクラス <i>B</i> が <code>super.clone()</code> を呼び出すなら、クラス <i>B</i> の <code>clone</code> メソッドは、型 <i>A</i> のオブジェクトを返す可能性が高いです。
これは <code>clone</code> のための汎用規約に違反します。
</p>
<p>
すべての <code>clone</code> メソッドが <code>super.clone()</code> を呼び出すなら <code>Object.clone()</code> が呼び出されることが保証され、常に正しい型のオブジェクトが返されます。
</p>

    
<h3><a name="CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE">CN: Cloneable を実装していないクラスが clone メソッドを定義している (CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE)</a></h3>


<p>
このクラスは、<code>Cloneable</code> を実装していないのに <code>clone</code> メソッドを定義しています。
これが OK (たとえば、サブクラスのクローンの実装を自分自身で制御したい場合です) という状況もありますが意図したことなのか確認してください。
</p>

    
<h3><a name="CNT_ROUGH_CONSTANT_VALUE">CNT: 既知の定数の雑な値を見つける (CNT_ROUGH_CONSTANT_VALUE)</a></h3>


<p>
コードの明確さともっと良い正確さのために定義済みライブラリ定数を使うことを推奨します。
</p>


<h3><a name="CO_ABSTRACT_SELF">Co: 抽象クラスは共変な compareTo メソッドを定義している (CO_ABSTRACT_SELF)</a></h3>


<p>
このクラスは、共変な <code>compareTo</code> メソッドを定義しています。
<code>Comparable</code> インタフェースの <code>compareTo</code> メソッドを正しく実装するためには <code>compareTo</code> メソッドのパラメータの型は、<code>java.lang.Object</code> でなければなりません。
</p>

    
<h3><a name="CO_SELF_NO_OBJECT">Co: 共変な compareTo メソッドの定義 (CO_SELF_NO_OBJECT)</a></h3>


<p>
このクラスは、共変な <code>compareTo</code> メソッドを定義しています。
<code>Comparable</code> インタフェースの <code>compareTo</code> メソッドを正しく実装するためには <code>compareTo</code> メソッドのパラメータの型は、<code>java.lang.Object</code> でなければなりません。
</p>

    
<h3><a name="DE_MIGHT_DROP">DE: 例外を捨てているかもしれないメソッド (DE_MIGHT_DROP)</a></h3>


<p>
このメソッドは、例外を捨てているかもしれません。
一般にキャッチした例外は何らかの方法で処理、または報告するべきです、あるいはメソッドからスローするべきです。
</p>

    
<h3><a name="DE_MIGHT_IGNORE">DE: 例外を無視しているかもしれないメソッド (DE_MIGHT_IGNORE)</a></h3>


<p>
このメソッドは例外を無視しているかもしれません。
一般に例外は何らかの方法で処理、または報告するべきです、あるいはメソッドからスローするべきです。
</p>

    
<h3><a name="DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS">DMI: エントリセットの要素を加えることは、Entry オブジェクトの再利用のために失敗するかもしれない (DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS)</a></h3>


<p>
entrySet メソッドは、一つの Entry オブジェクトを再利用し、反復中に返される基底 Map のビューを返すことが許可されています。
Java 1.6 の時点で、IdentityHashMap と EnumMap の両方がそうしました。
そのような Map を通して繰り返すとき、エントリ値は次の繰り返しへ進むまでが有効です。
たとえば、addAll メソッドにそのような entrySet を渡そうと試みるのは、ひどく間違っているでしょう。
</p>

    
<h3><a name="DMI_RANDOM_USED_ONLY_ONCE">DMI: Random オブジェクトが作成され1度しか使われない (DMI_RANDOM_USED_ONLY_ONCE)</a></h3>


<p>
このコードは、<code>java.util.Random</code> オブジェクトを作成して1つの乱数を生成するために使用して捨てています。
これはあまり良くない品質の乱数を作り出し、効率が悪いです。
できれば、<code>Random</code> オブジェクトを1つだけ作成して保存されるようにコードを書き直してください。
そして、新しい乱数が必要なたびに既存の <code>Random</code> オブジェクトでメソッドを呼び出してください。
</p>
<p>
生成された乱数が推測可能でないことが重要なら、乱数ごとに新しい <code>Random</code> オブジェクトを作成してはいけません (値はあまりに簡単に推測可能です)。
その代わりに <code>java.security.SecureRandom</code> の使用を強く検討するべきです (そして必要とされる乱数ごとに新しい <code>SecureRandom</code> のオブジェクトを作成することを回避します)。 
</p>

    
<h3><a name="DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION">DMI: コレクションを消去するために removeAll メソッドを使用しない (DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION)</a></h3>


<p>
コレクション <code>c</code> からすべての要素を除去したいなら、<code>c.removeAll(c)</code> ではなく <code>c.clear</code> を使用してください。
コレクションを消去するために <code>c.removeAll(c)</code> を呼び出すことは、それほど明確ではなく、タイプミスからの誤りに影響されやすく、効率的ではなく、いくつかのコレクションでは、<code>ConcurrentModificationException</code> をスローするかもしれません。
</p>

    
<h3><a name="DM_EXIT">Dm: System.exit(...) を呼び出しているメソッド (DM_EXIT)</a></h3>


<p>
<code>System.exit(...)</code> を呼び出すことは、Java 仮想マシン全体をシャットダウンさせてしまいます。
それが適切な場合にだけ使用するべきです。
<code>System.exit(...)</code> の呼び出しはコードが他のコードによって呼び出されることを困難か不可能にします。
その代わりに RuntimeException をスローすることを検討してください。
</p>

    
<h3><a name="DM_RUN_FINALIZERS_ON_EXIT">Dm: 危険なメソッド runFinalizersOnExit を呼び出しているメソッド (DM_RUN_FINALIZERS_ON_EXIT)</a></h3>


<p>
どんな理由があるにせよ決して <code>System.runFinalizersOnExit</code> と <code>Runtime.runFinalizersOnExit</code> を呼び出さないでください。
Java ライブラリで最も危険なメソッドの1つです。 -- Joshua Bloch
</p>

    
<h3><a name="ES_COMPARING_PARAMETER_STRING_WITH_EQ">ES: String パラメータを == や != を使用して比較している (ES_COMPARING_PARAMETER_STRING_WITH_EQ)</a></h3>


<p>
このコードは、参照等価性のために == や != を使用して <code>java.lang.String</code> パラメータを比較しています。
文字列定数または正準化された文字列だけをメソッドに渡すことを呼び出し元に要求することは必要以上に脆弱で測定可能な性能の向上をもたらしません。
その代わりに <code>equals(Object)</code> メソッドを使うことを検討してください。
</p>

    
<h3><a name="ES_COMPARING_STRINGS_WITH_EQ">ES: String オブジェクトを == や != を使用して比較している (ES_COMPARING_STRINGS_WITH_EQ)</a></h3>


<p>
このコードは、参照等価性のために == や != を使用して <code>java.lang.String</code> オブジェクトを比較しています。
両方の文字列がソースファイルの定数か、<code>String.intern()</code> を使用して正準化されていないかぎり、同じ文字列は2つの異なる String オブジェクトによって表されるかもしれません。
その代わりに <code>equals(Object)</code> メソッドを使うことを検討してください。
</p>

    
<h3><a name="EQ_ABSTRACT_SELF">Eq: 抽象クラスは共変な equals メソッドを宣言している (EQ_ABSTRACT_SELF)</a></h3>


<p>
このクラスは、共変な <code>equals</code> メソッドを定義しています。
<code>java.lang.Object</code> の <code>equals</code> メソッドを正しくオーバーライドするためには <code>equals</code> メソッドのパラメータの型は、<code>java.lang.Object</code> でなければなりません。
</p>

    
<h3><a name="EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS">Eq: equals メソッドは互換性のないオペランドをチェックしている (EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS)</a></h3>


<p>
この <code>equals</code> メソッドは、引数が互換性のない型 (すなわちスーパタイプでもなく、<code>equals</code> メソッドを定義しているクラスのスーパータイプでもサブタイプでもないクラス) なのか確かめています。
たとえば、<code>Foo</code> クラスの <code>equals</code> メソッドはそのように見えるかもしれません。
</p>
<blockquote><pre>
public boolean equals(Object o) {
    if (o instanceof Foo)
        return name.equals(((Foo)o).name);
    else if (o instanceof String)
        return name.equals(o);
    else return false;
}
</pre></blockquote>
<p>
これは対称的で推移的である <code>equals</code> メソッドを実現するのはとても難しいので、間違ったプラクティスと見なされています。
プロパティがなければまったく予想していない振る舞いが起こりえます。
</p>

    
<h3><a name="EQ_COMPARETO_USE_OBJECT_EQUALS">Eq: compareTo(...) メソッドを定義して Object.equals() を使用しているクラス (EQ_COMPARETO_USE_OBJECT_EQUALS)</a></h3>


<p>
このクラスは、<code>compareTo(...)</code> メソッドを定義していますが、<code>equals</code> メソッドは <code>java.lang.Object</code> から継承しています。
一般に、<code>equals</code> メソッドが true を返す場合に限り、<code>compareTo</code> メソッドは0を返すべきです。
これが違反されるなら奇妙で予測できない失敗が PriorityQueue などのクラスで発生します。
J2SE 5.0では、<code>PriorityQueue.remove()</code> は <code>compareTo</code> メソッドを使用しますが、Java SE 6では、<code>equals</code> メソッドを使用します。
</p>
<p>
Comparable インタフェースの compareTo メソッドの JavaDoc を以下に引用します。
</p>
<blockquote><p>
必須というわけではありませんが、<code>(x.compareTo(y)==0) == (x.equals(y))</code> であることが強く推奨されます。
一般に、<code>Comparable</code> インタフェースを実装しているクラスで、この条件に違反するクラスは明確にこの事実を示す必要があります。
「注:このクラスは <code>equals</code> と一貫性のない自然順序付けを持ちます」などと明示することをお勧めします。
</p></blockquote>

    
<h3><a name="EQ_GETCLASS_AND_CLASS_CONSTANT">Eq: equals メソッドはサブタイプのために失敗する (EQ_GETCLASS_AND_CLASS_CONSTANT)</a></h3>


<p>
このクラスは、サブクラスによる継承によって壊れる <code>equlas</code> メソッドがあります。
<code>equals</code> メソッドは、クラスリテラルを引数のクラスと比較しています (たとえば、<code>Foo</code> クラスで <code>Foo.class == o.getClass()</code> のような判定を行っています)。
<code>this.getClass() == o.getClass()</code> の方がより良いです。
</p>

    
<h3><a name="EQ_SELF_NO_OBJECT">Eq: 共変な equals メソッドの定義 (EQ_SELF_NO_OBJECT)</a></h3>


<p>
このクラスは、共変な <code>equals</code> メソッドを定義しています。
<code>java.lang.Object</code> の <code>equals</code> メソッドを正しくオーバーライドするためには <code>equals</code> メソッドのパラメータの型は、<code>java.lang.Object</code> でなければなりません。
</p>

    
<h3><a name="FI_EMPTY">FI: 空のファイナライザは削除するべき (FI_EMPTY)</a></h3>


<p>
空の <code>finalize</code> メソッドは役に立たないので削除するべきです。
</p>

    
<h3><a name="FI_EXPLICIT_INVOCATION">FI: ファイナライザの明示的な呼び出し (FI_EXPLICIT_INVOCATION)</a></h3>


<p>
このメソッドには明示的にオブジェクトで <code>finalize</code> メソッドの呼び出しがあります。
ファイナライザは Java 仮想マシンによって1度だけ実行されることになっているので、これは間違った考えです。
</p>
<p>
参照によってつながった複数のオブジェクトがファイナライズ可能になると、Java 仮想マシンはすべてのオブジェクトの <code>finalize</code> メソッドを呼び出します。
おそらく異なるスレッドで同時にです。
したがって、クラス <i>X</i> の <code>finalize</code> メソッドの中から <i>X</i> によって参照されているオブジェクトの <code>finalize</code> メソッドを呼び出すのは、とりわけ間違った考えです。
なぜなら、オブジェクトがすでに別のスレッドによってファイナライズされているかもしれないからです。 
</p>

    
<h3><a name="FI_FINALIZER_NULLS_FIELDS">FI: ファイナライザはフィールドを null にする (FI_FINALIZER_NULLS_FIELDS)</a></h3>


<p>
このファイナライザは、フィールドを null にしています。
これは通常誤りでガベージコレクタを助けません。オブジェクトはいずれにしろガベージされます。
</p>

    
<h3><a name="FI_FINALIZER_ONLY_NULLS_FIELDS">FI: ファイナライザはフィールドを null にするだけ (FI_FINALIZER_ONLY_NULLS_FIELDS)</a></h3>


<p>
このファイナライザは、フィールドを null にすること以外に何もしません。
これはまったく無意味であり、オブジェクトがガベージされ、ファイナライズされ、再びガベージされることを要求しています。
<code>finalize</code> メソッドを削除するべきです。
</p>

    
<h3><a name="FI_MISSING_SUPER_CALL">FI: ファイナライザはスーパークラスのファイナライザを呼び出していない (FI_MISSING_SUPER_CALL)</a></h3>


<p>
この <code>finalize</code> メソッドは、スーパークラスの <code>finalize</code> メソッドを呼び出していません。
したがって、スーパークラスのために定義されたどんなファイナライザアクションも実行されません。
<code>super.finalize()</code> の呼び出しを追加してください。
</p>

    
<h3><a name="FI_NULLIFY_SUPER">FI: ファイナライザはスーパークラスのファイナライザを無効にしている (FI_NULLIFY_SUPER)</a></h3>


<p>
この空の <code>finalize</code> メソッドは、明示的にスーパークラスによって定義されたどんなファイナライザの効果も無効にします。
スーパークラスのために定義されたどんなファイナライザアクションも実行されません。
これが意図したことではない場合、メソッドを削除してください。
</p>

    
<h3><a name="FI_USELESS">FI: ファイナライザはスーパークラスのファイナライザを呼び出しているだけ (FI_USELESS)</a></h3>


<p>
この <code>finalize</code> メソッドは、スーパークラスの <code>finalize</code> メソッドを呼び出しているだけです。
冗長なので削除してください。
</p>

    
<h3><a name="VA_FORMAT_STRING_USES_NEWLINE">FS: 書式文字列は \n よりも %n を使用するべき (VA_FORMAT_STRING_USES_NEWLINE)</a></h3>


<p>
この書式文字列には改行文字 (\n) が含まれています。
一般に書式文字列には %n を使用することがより望ましいです。%n は、プラットホーム特有の行セパレータを作り出します。
</p>

  
<h3><a name="GC_UNCHECKED_TYPE_IN_GENERIC_CALL">GC: 検査されない型への総称呼び出し (GC_UNCHECKED_TYPE_IN_GENERIC_CALL)</a></h3>


<p>
総称型パラメータからの特定の型が予想される Object 型をコンパイルするとき、総称型コレクションメソッドへの呼び出しは引数を渡します。
したがって、標準の Java 型システムも静的解析もパラメータとして渡されているオブジェクトが適切な型かどうかに関する有効な情報を提供できません。
</p>

    
<h3><a name="HE_EQUALS_NO_HASHCODE">HE: equals メソッドは定義していますが hashCode メソッドは定義していないクラス (HE_EQUALS_NO_HASHCODE)</a></h3>


<p>
このクラスは、<code>equals(Object)</code> メソッドをオーバーライドしていますが、<code>hashCode</code> メソッドはオーバーライドしていません。
したがって、「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>

    
<h3><a name="HE_EQUALS_USE_HASHCODE">HE: equals メソッドを定義して Object.hashCode() を使用しているクラス (HE_EQUALS_USE_HASHCODE)</a></h3>


<p>
このクラスは、<code>equals(Object)</code> をオーバーライドしていますが、<code>hashCode</code> メソッドは <code>java.lang.Object</code> から継承しています (同一性ハッシュコード (Java 仮想マシンによってオブジェクトに代入された任意の値) を返します)。
したがって、「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>
<p>
このクラスのインスタンスが HashMap/HashTable に決して代入されるだろうと思わないなら推奨される <code>hashCode</code> メソッドの実装は以下のようになります。
</p>
<blockquote><pre>
public int hashCode() {
    assert false : "hashCodeが呼び出されることは想定されていません。";
    return 42; // 適当な値 
}
</pre></blockquote>

    
<h3><a name="HE_HASHCODE_NO_EQUALS">HE: hashCode メソッドを定義していますが equals メソッドは定義していないクラス (HE_HASHCODE_NO_EQUALS)</a></h3>


<p>
このクラスは、<code>hashCode</code> メソッドを定義していますが、<code>equals</code> メソッドは定義していません。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>

    
<h3><a name="HE_HASHCODE_USE_OBJECT_EQUALS">HE: hashCode メソッドを定義して Object.equals() を使用しているクラス (HE_HASHCODE_USE_OBJECT_EQUALS)</a></h3>


<p>
このクラスは、<code>hashCode</code> メソッドを定義していますが、 <code>equals</code> メソッドは <code>java.lang.Object</code> から継承しています (オブジェクトの参照比較で等価性を判定します)。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に従っているかもしれませんが、
おそらく、<code>hashCode</code> メソッドをオーバーライドすることによって意図されたことではありません。
(<code>hashCode</code> メソッドをオーバーライドすることは、オブジェクトの同一性が単純な参照等価性よりも複雑な規約に基づくことを意味します)。
</p>
<p>
このクラスのインスタンスが HashMap/HashTable に決して代入されるだろうと思わないなら推奨される <code>hashCode</code> メソッドの実装は以下のようになります。
</p>
<blockquote><pre>
public int hashCode() {
    assert false : "hashCodeが呼び出されることは想定されていません。";
    return 42; // 適当な値 
}
</pre></blockquote>

    
<h3><a name="HE_INHERITS_EQUALS_USE_HASHCODE">HE: equals メソッドを継承して Object.hashCode() を使用しているクラス (HE_INHERITS_EQUALS_USE_HASHCODE)</a></h3>


<p>
このクラスは、抽象スーパークラスから <code>equals(Object)</code> メソッドを継承して、<code>java.lang.Object</code> から <code>hashCode</code> メソッドを継承しています (同一性ハッシュコード (Java 仮想マシンによってオブジェクトに代入された任意の値) を返します)。
したがって、「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>
<p>
<code>hashCode</code> メソッドを定義したくないまたはオブジェクトが HashMap/Hashtable に決して格納されないだろうと思っているなら <code>UnsupportedOperationException</code> をスローする <code>hashCode()</code> メソッドを定義してください。
</p>

    
<h3><a name="IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">IC: スーパークラスは初期化中にサブクラスを使用している (IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION)</a></h3>


<p>
クラスは、初期化中にサブクラスを積極的に使用しています。サブクラスはこの時点ではまだ初期化されていません。<br>
たとえば、以下のコードにおいて、<code>foo</code> は null です。
</p>
<blockquote><pre>
public class CircularClassInitialization {
    static class InnerClassSingleton extends CircularClassInitialization {
        static InnerClassSingleton singleton = new InnerClassSingleton();
    }
    
    static CircularClassInitialization foo = InnerClassSingleton.singleton;
}
</pre></blockquote>

    
<h3><a name="IMSE_DONT_CATCH_IMSE">IMSE: 疑わしい IllegalMonitorStateException のキャッチ (IMSE_DONT_CATCH_IMSE)</a></h3>


<p>
<code>IllegalMonitorStateException</code> は、一般に設計上の欠陥 (ロックを保持していないオブジェクトで <code>wait</code> メソッドまたは <code>notify</code> メソッドを呼び出す) の場合にだけスローされます。
</p>

    
<h3><a name="ISC_INSTANTIATE_STATIC_CLASS">ISC: static メソッドだけを提供するクラスの不必要なインスタンス化 (ISC_INSTANTIATE_STATIC_CLASS)</a></h3>


<p>
このクラスは、static メソッドだけを提供するクラスのオブジェクトを作成しています。
このオブジェクトは作成する必要はありません。修飾子として直接クラス名を使用する static メソッドにアクセスしてください。
</p>

    
<h3><a name="IT_NO_SUCH_ELEMENT">It: Iterator.next() が NoSuchElementException をスローできない (IT_NO_SUCH_ELEMENT)</a></h3>


<p>
このクラスは、<code>java.util.Iterator</code> を実装しています。
しかしながら、<code>next</code> メソッドは <code>java.util.NoSuchElementException</code> をスローできません。
<code>next</code> メソッドは、それ以上要素を返すことができないときは <code>NoSuchElementException</code> をスローするように変更するべきです。
</p>

    
<h3><a name="J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION">J2EE: HttpSession への非直列化可能オブジェクトの格納 (J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION)</a></h3>


<p>
このコードは、HttpSession に非直列化可能オブジェクトを格納していると思われます。
このセッションが不活性化されるか移行したなら、エラーを招きます。
</p>

    
<h3><a name="JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">JCIP: 不変クラスのフィールドは final にすべき (JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS)</a></h3>


<p>
クラスは、net.jcip.annotations.Immutable または javax.annotation.concurrent.Immutable でアノテートされています。
アノテーションのルールは、すべてのフィールドが final であることを義務づけます。
</p>

    
<h3><a name="NP_BOOLEAN_RETURN_NULL">NP: 戻り型が Boolean のメソッドが明示的に null を返している (NP_BOOLEAN_RETURN_NULL)</a></h3>


<p>
Boolean.TRUE、Boolean.FALSE、null を返すメソッドはいつ事故が起きてもおかしくないです。
まるで論理型の値を返すかのように、このメソッドは呼び出される可能性があります。
コンパイラは Boolean 値のオートアンボクシングを挿入します。
null 値が返されるなら NullPointerException が発生することになります。
</p>

    
<h3><a name="NP_CLONE_COULD_RETURN_NULL">NP: null を返すかもしれない clone メソッド (NP_CLONE_COULD_RETURN_NULL)</a></h3>


<p>
この <code>clone</code> メソッドは、いくつかの条件で null を返すと思われます。
しかし、<code>clone</code> メソッドは決して null を返すのは許されません。
この経路が到達できないことを確信しているなら、代わりに <code>AssertionError</code> をスローしてください。
</p>

    
<h3><a name="NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT">NP: equals メソッドは null の引数をチェックしていない (NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT)</a></h3>


<p>
この <code>equals(Object)</code> メソッドの実装は引数として渡されている null をチェックしていないので、<code>java.lang.Object.equals()</code> で定義された規約に違反しています。
すべての <code>equals</code> メソッドは引数に null が渡されたなら false を返すべきです。
</p>

    
<h3><a name="NP_TOSTRING_COULD_RETURN_NULL">NP: null を返すかもしれない toString メソッド (NP_TOSTRING_COULD_RETURN_NULL)</a></h3>


<p>
この <code>toString</code> メソッドは、いくつかの条件で null を返すと思われます。
仕様を寛大に読むとこれが許されると解釈できるかもしれませんが、それはおそらく間違った考えで、他のコードが壊れる原因になる可能性があります。
null ではなく空の文字列または、いくつかの他の適切な文字列を返してください。
</p>

    
<h3><a name="NM_CLASS_NAMING_CONVENTION">Nm: クラス名は大文字から始めるべき (NM_CLASS_NAMING_CONVENTION)</a></h3>


<p>
クラス名は、最初の文字とそれに続く各単語の最初の文字を大文字にした名詞にすべきです。
クラス名は単純でわかりやすいようにしてください。
頭文字や略語 (URLやHTMLなどのように略語がロング形式よりもはるかに広く使われている場合を除く) の使用は避けてください。
</p>

    
<h3><a name="NM_CLASS_NOT_EXCEPTION">Nm: 例外クラスのように命名されているが、クラスは Exception から派生されていない (NM_CLASS_NOT_EXCEPTION)</a></h3>


<p>
このクラスは、例外クラスから派生されていないのにクラス名が「Exception」で終わっています。
これは、このクラスのユーザに紛らわしいです。
</p>

    
<h3><a name="NM_CONFUSING">Nm: 紛らわしい名前のメソッド (NM_CONFUSING)</a></h3>


<p>
参照されたメソッドは、大文字の使い方だけによって異なる名前があります。
</p>

    
<h3><a name="NM_FIELD_NAMING_CONVENTION">Nm: フィールド名は小文字から始めるべき (NM_FIELD_NAMING_CONVENTION)</a></h3>


<p>
final でないフィールドの名前は、最初の文字は小文字にし、それに続く各単語の最初の文字を大文字にすべきです。
</p>

    
<h3><a name="NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER">Nm: Java の後のバージョンのキーワードである識別子を使用している (NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER)</a></h3>


<p>
識別子は、Java の後のバージョンのキーワードとして予約されている単語です。
コードを Java の後のバージョンでコンパイルするためには変更する必要があります。
</p>

    
<h3><a name="NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER">Nm: Java の後のバージョンのキーワードである識別子を使用している (NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER)</a></h3>


<p>
この識別子は、Java の後のバージョンのキーワードとして使われます。
このコードと API を参照するどんなコードも、Java の後のバージョンでコンパイルするためには変更する必要があります。
</p>

    
<h3><a name="NM_METHOD_NAMING_CONVENTION">Nm: メソッド名は小文字から始めるべきです (NM_METHOD_NAMING_CONVENTION)</a></h3>


<p>
メソッド名は、最初の文字は小文字にし、それに続く各単語の最初の文字を大文字にした動詞にすべきです。
</p>

    
<h3><a name="NM_SAME_SIMPLE_NAME_AS_INTERFACE">Nm: クラス名は実装されたインタフェースの単純名を遮るべきではない (NM_SAME_SIMPLE_NAME_AS_INTERFACE)</a></h3>


<p>
このクラスまたはインタフェースは、、インタフェースが異なるパッケージであるということを除いて実装された/拡張されたインタフェースと同一の単純名です (たとえば、<code>alpha.Foo</code> が <code>beta.Foo</code> を継承しているような状況です)。
これは非常に紛らわしく、参照関係を解決するために import 文を見なければならなかったり、スーパークラスに存在するメソッドを誤ってオーバーライドしてしまったりする状況を作り出します。
</p>

    
<h3><a name="NM_SAME_SIMPLE_NAME_AS_SUPERCLASS">Nm: クラス名はスーパークラスの単純名を遮るべきではない (NM_SAME_SIMPLE_NAME_AS_SUPERCLASS)</a></h3>


<p>
このクラスは、スーパークラスが異なるパッケージであるということを除いて、スーパークラスと同一の単純名をです (たとえば、<code>alpha.Foo</code> が <code>beta.Foo</code> を拡張します)。
これは非常に紛らわしく、参照関係を解決するために import 文を見なければならなかったり、スーパークラスに存在するメソッドを誤ってオーバーライドしてしまったりする状況を作り出します。
</p>

    
<h3><a name="NM_VERY_CONFUSING_INTENTIONAL">Nm: 非常に紛らわしい名前のメソッド (多分意図的) (NM_VERY_CONFUSING_INTENTIONAL)</a></h3>


<p>
参照されたメソッドは、大文字の使い方だけによって異なる名前があります。
大文字の使い方が同一ならメソッドの1つが他のメソッドをオーバーライドするので、非常に紛らわしいです。
他のメソッドの存在から、これらのメソッドの両方の存在が意図的で、確実に混乱させていると思われます。
APIの凍結によって両方とも持たざるを得ない場合を除き、それらのうちの1つを削除しようと努力するべきです。 
</p>

    
<h3><a name="NM_WRONG_PACKAGE_INTENTIONAL">Nm: パラメータの間違ったパッケージのためにスーパークラスのメソッドをオーバーライドしていないメソッド (NM_WRONG_PACKAGE_INTENTIONAL)</a></h3>


<p>
パラメータの型が正確にスーパークラスで対応するパラメータの型と合致していないので、サブクラスのメソッドはスーパークラスの類似したメソッドをオーバーライドしていません。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
import alpha.Foo;

public class A {
    public int f(Foo x) { return 17; }
}
----
import beta.Foo;

public class B extends A {
    public int f(Foo x) { return 42; }
    public int f(alpha.Foo x) { return 27; }
}
</pre></blockquote>
<p>
クラス <code>B</code> で定義された <code>f(Foo)</code> メソッドは、クラス <code>A</code> の <code>f(Foo)</code> メソッドをオーバーライドしません。
これは引数の型 <code>Foo</code> が違うパッケージだからです。
</p>
<p>
この場合、サブクラスがスーパークラスのメソッドと同一のシグネチャでメソッドを定義しているので、おそらく理解できます。
しかしながら、そのようなメソッドは非常に紛らわしいです。
類似しているが同一ではないシグネチャのメソッドを除去するか、非推奨にすることを強く検討するべきです。
</p>

    
<h3><a name="ODR_OPEN_DATABASE_RESOURCE">ODR: データベースリソースのクローズに失敗するかもしれないメソッド (ODR_OPEN_DATABASE_RESOURCE)</a></h3>


<p>
このメソッドは、データベースリソース (たとえば、データベースコネクションや行セット) を作成していますが、どんなフィールドにも代入していないか、他のメソッドにも渡していないか、戻り値にもしていません。
そして、メソッドからのすべての経路でオブジェクトをクローズするように見えません。
メソッドからのすべての経路でデータベースリソースのクローズ失敗は良くない性能になるかもしれません。
データベースとの通信で問題があるアプリケーションの原因になる可能性があります。
</p>

    
<h3><a name="ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH">ODR: 例外経路でデータベースリソースのクローズに失敗するかもしれないメソッド (ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH)</a></h3>


<p>
このメソッドは、データベースリソース (たとえば、データベースコネクションや行セット) を作成していますが、どんなフィールドにも代入していないか、他のメソッドにも渡していないか、戻り値にもしていません。
そして、メソッドからのすべての例外経路でオブジェクトをクローズするように見えません。
メソッドからのすべての経路でデータベースリソースのクローズ失敗は良くない性能になるかもしれません。
データベースとの通信で問題があるアプリケーションの原因になる可能性があります。
</p>

    
<h3><a name="OS_OPEN_STREAM">OS: ストリームのクローズに失敗するかもしれないメソッド (OS_OPEN_STREAM)</a></h3>


<p>
このメソッドは、入出力ストリームオブジェクトを作成していますが、どんなフィールドにも代入していないしクローズするかもしれない別のメソッドにも渡していなくて、戻り値にしてもいません。そして、メソッドからのすべての経路でクローズするように見えません。
これは、ファイルディスクリプタリークになるかもしれません。
ストリームがクローズされることを確実にするために <code>finally</code> ブロックを使うことは、一般に良い考えです。
</p>

    
<h3><a name="OS_OPEN_STREAM_EXCEPTION_PATH">OS: 例外経路でストリームのクローズに失敗するかもしれないメソッド (OS_OPEN_STREAM_EXCEPTION_PATH)</a></h3>


<p>
このメソッドは、入出力ストリームオブジェクトを作成していますが、どんなフィールドにも代入していないしクローズするかもしれない別のメソッドにも渡していないくて、戻り値にしてもいません。そして、メソッドからのすべての可能性がある例外経路でクローズするように見えません。
これはファイルディスクリプターリークになるかもしれません。
ストリームがクローズされることを確実にするために <code>finally</code> ブロックを使うことは、一般に良い考えです。
</p>

    
<h3><a name="PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS">PZ: 繰り返しでエントリオブジェクトを再利用しない (PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS)</a></h3>


<p>
このクラスは、Iterator と Map.Entry で基底 Map のビューを返すことを許可された両方の entrySet メソッドがあります。
この巧妙なアイデアは、Map 実装で使用されましたが、厄介なコーディング間違いの可能性を取り込みました。
Map <code>m</code> が entrySet のためのそのような反復子を返すならば、<code>c.addAll(m.entrySet())</code> はひどく間違っているでしょう。
OpenJDK 1.7 の すべての Map 実装はこれを回避するために書き直されました。
</p>

    
<h3><a name="RC_REF_COMPARISON_BAD_PRACTICE">RC: 定数への疑わしい参照比較 (RC_REF_COMPARISON_BAD_PRACTICE)</a></h3>


<p>
このメソッドは、 参照値を == または != 演算子を使用して定数と比較しています。
この型のインスタンスを比較する正しい方法は、一般に <code>equals</code> メソッドです。
等価で識別可能なインスタンスを作成する可能性がありますが異なるオブジェクトなので == で比較しないでください。
参照によって一般に比較されるべきではないクラスの例は、<code>java.lang.Integer</code> 、<code>java.lang.Float</code> などです。
</p>

    
<h3><a name="RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN">RC: Boolean 値の疑わしい参照比較 (RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN)</a></h3>


<p>
このメソッドは、== または != 演算子を使用して2つの Boolean 値を比較しています。
一般には2つの Boolean 値 (<code>Boolean.TRUE</code> と <code>Boolean.FALSE</code>) だけですが、
<code>new Boolean(b)</code> コンストラクタを使用して他の Boolean オブジェクトを作成する可能性があります。
そのようなオブジェクトを回避することは最高です。
しかし、それらが存在するなら、Boolean オブジェクトの等価性をチェックするために <code>.equals(...)</code> ではなく == または != を使用しているなら異なる結果をもたらします。
</p>

    
<h3><a name="RR_NOT_CHECKED">RR: InputStream.read() の戻り値を無視しているメソッド (RR_NOT_CHECKED)</a></h3>


<p>
このメソッドは、複数バイトを返す可能性がある <code>java.io.InputStream.read()</code> (またはそのバリエーション) の戻り値を無視しています。
戻り値がチェックされないと呼び出し元は要求したバイト数よりも少ないバイト数を読み出した場合、正しく処理できません。
これは潜在的なバグで、多くのプログラムでは、入力ストリームからの読み出しは、通常要求した完全なデータ量を読み出しますが、散発的に失敗することがあります。
</p>

    
<h3><a name="SR_NOT_CHECKED">RR: InputStream.skip() の戻り値を無視しているメソッド (SR_NOT_CHECKED)</a></h3>


<p>
このメソッドは、複数バイトをスキップする可能性がある <code>java.io.InputStream.skip()</code> の戻り値を無視しています。
戻り値がチェックされないと呼び出し元は要求したバイト数よりも少ないバイト数しかスキップしなかった場合、正しく処理できません。 
これは潜在的なバグで、多くのプログラムでは、入力ストリームからのスキップは、通常要求した完全なデータ量をスキップをしますが、散発的に失敗することがあります。 
しかしながら、バッファードストリーム での <code>skip</code> メソッドはバッファのデータをスキップするので要求されたバイト数のスキップは常に失敗します。
</p>

    
<h3><a name="RV_NEGATING_RESULT_OF_COMPARETO">RV: compareTo()/compare() の結果を無効にする (RV_NEGATING_RESULT_OF_COMPARETO)</a></h3>


<p>
このコードは、<code>compareTo</code> または <code>compare</code> メソッドの戻り値を無効にしています。
これは疑わしいか間違ったプログラミングプラクティスです。戻り値が Integer.MIN_VALUE なので、戻り値を無効にすることは結果の符号を無効にしません。
結果を無効にするのではなくオペランドの順序を逆にすることによって、同じ意図した結果を得ることができます。
</p>

    
<h3><a name="RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">RV: 例外的戻り値を無視しているメソッド (RV_RETURN_VALUE_IGNORED_BAD_PRACTICE)</a></h3>


<p>
このメソッドはチェックされていない値を返しています。
戻り値は異常か予想外の実行結果を示す可能性があるのでチェックするべきです。
たとえば、<code>File.delete()</code> はファイルをうまく削除できなかったなら、例外をスローするのではなく false を返します。
結果をチェックしないなら例外的戻り値を返すメソッドの呼び出しで予想外の振る舞いの合図に気づきません。
</p>

    
<h3><a name="SI_INSTANCE_BEFORE_FINALS_ASSIGNED">SI: スタティックイニシャライザは、すべての static final フィールドが代入される前にインスタンスを作成する (SI_INSTANCE_BEFORE_FINALS_ASSIGNED)</a></h3>


<p>
すべての static final フィールドが初期化される前に、スタティックイニシャライザがクラスのインスタンスを作成します。
</p>

    
<h3><a name="SW_SWING_METHODS_INVOKED_IN_SWING_THREAD">SW: Swing メソッドは AWT イベントディスパッチスレッドから呼び出す必要がある (SW_SWING_METHODS_INVOKED_IN_SWING_THREAD)</a></h3>


<p>
(<a href="http://web.archive.org/web/20090526170426/http://java.sun.com/developer/JDCTechTips/2003/tt1208.html">From JDC Tech Tip</a>)<br>
に解説されているとおり、Swing のメソッド、<code>show</code> メソッド、<code>setVisible</code> メソッド、<code>pack</code> メソッドは、フレームのために関連したピアを作成します。
ピアの作成で、システムはイベントディスパッチスレッドを作成します。
これが問題になることがあります。なぜなら <code>pack</code> メソッドと <code>validate</code> メソッドがまだ処理中でもイベントディスパッチスレッドがリスナに通知できるからです。
この状況は、2つのスレッドが Swing コンポーネントにアクセスする可能性があり、デッドロックや、その他のスレッドに関する問題になる可能性がある重大な欠陥です。
<code>pack</code> メソッドの呼び出しはコンポーネントを実体化させます。実体化しているときに、イベントディスパッチスレッドがリスナへの通知を開始する可能性があります。
</p>

    
<h3><a name="SE_BAD_FIELD">Se: 直列化可能クラスの非 transient で非直列化可能なインスタンスフィールド (SE_BAD_FIELD)</a></h3>


<p>
この直列化可能クラスは、transient、Serializable、<code>java.lang.Object</code> でもない非プリミティブ型のインスタンスフィールドを定義して、
<code>Externalizable</code> インタフェースまたは <code>readObject</code> メソッドと <code>writeObject</code> メソッドを実装するように見えません。
また、<code>Externalizable</code> インタフェースも実装していなくて、<code>readObject</code> メソッドも <code>writeObject</code> メソッドも定義していません。
非直列化可能オブジェクトがこのフィールドに格納されるならクラスのオブジェクトは正しく直列化復元されません。
</p>

    
<h3><a name="SE_BAD_FIELD_INNER_CLASS">Se: 非直列化可能クラスに直列化可能な内部クラスがある (SE_BAD_FIELD_INNER_CLASS)</a></h3>


<p>
この直列化可能クラスは、非直列化可能クラスの内部クラスです。
内部クラスを直列化しようとすると関連する外部クラスのインスタンスを結びつけようとするので、実行時エラーの原因になります。
</p>
<p>
できれば、内部クラスを static にして問題を解決するべきです。
外部クラスを直列化可能にすることで動作するかもしれないが、内部クラスのインスタンスを直列化することは外部クラスも常に直列化することを意味します。
本当に望むことですか。
</p>

    
<h3><a name="SE_BAD_FIELD_STORE">Se: 非直列化可能な値を直列化可能クラスのインスタンスフィールドに格納している (SE_BAD_FIELD_STORE)</a></h3>


<p>
非直列化可能な値を直列化可能クラスの 非 transient フィールドに格納しています。
</p>

    
<h3><a name="SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">Se: Comparator は Serializable を実装していない (SE_COMPARATOR_SHOULD_BE_SERIALIZABLE)</a></h3>


<p>
このクラスは <code>Comparator</code> インタフェースを実装しています。
<code>Serializable</code> インタフェースも実装するべきかどうか検討するべきです。
コンパレータが <code>TreeMap</code> のような順序付きコレクションを構築するために使われるなら、コンパレータが直列化可能な場合だけ、<code>TreeMap</code> は直列化可能です。
大部分のコンパレータがほとんど状態を持たないとしても直列化可能にすることは簡単で良い防衛的なプログラミングです。
</p>

    
<h3><a name="SE_INNER_CLASS">Se: 直列化可能な内部クラス (SE_INNER_CLASS)</a></h3>


<p>
この直列化可能なクラスは内部クラスです。内部クラスを直列化しようとすると関連した外部クラスのインスタンスも直列化します。
外部クラスのインスタンスは直列化可能なので失敗しませんが、意図したことよりもっとずっと多くのデータを直列化するかもしれません。
できれば、内部クラスを static にして問題を解決するべきです。
</p>

    
<h3><a name="SE_NONFINAL_SERIALVERSIONID">Se: serialVersionUID が final ではない (SE_NONFINAL_SERIALVERSIONID)</a></h3>


<p>
このクラスは、final でない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは final とすべきです。
</p>

    
<h3><a name="SE_NONLONG_SERIALVERSIONID">Se: serialVersionUID が long ではない (SE_NONLONG_SERIALVERSIONID)</a></h3>


<p>
このクラスは、long でない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは long とすべきです。
</p>

    
<h3><a name="SE_NONSTATIC_SERIALVERSIONID">Se: serialVersionUID が static ではない (SE_NONSTATIC_SERIALVERSIONID)</a></h3>


<p>
このクラスは、static でない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは static とすべきです。
</p>

    
<h3><a name="SE_NO_SUITABLE_CONSTRUCTOR">Se: Serializable なクラスのスーパークラスで、引数なしコンストラクタを定義していない (SE_NO_SUITABLE_CONSTRUCTOR)</a></h3>


<p>
このクラスは <code>Serializable</code> インタフェースを実装していますが、そのスーパークラスは実装していません。
そのようなオブジェクトが直列化復元されるとき、スーパークラスのフィールドはスーパークラスの引数なしコンストラクタを呼び出すことによって初期化される必要があります。
スーパークラスには引数なしコンストラクタがないので、直列化と直列化復元は実行時に失敗します。
</p>

    
<h3><a name="SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION">Se: Externalizable なクラスが引数なしコンストラクタを定義していない (SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION)</a></h3>


<p>
このクラスは、<code>Externalizable</code> インタフェースを実装していますが、引数なしコンストラクタを定義していません。
<code>Externalizable</code> オブジェクトが直列化復元されるときは、最初に引数なしコンストラクタを呼び出すことによって構築される必要があります。
このクラスには引数なしコンストラクタがないので、直列化と直列化復元は実行時に失敗します。
</p>

    
<h3><a name="SE_READ_RESOLVE_MUST_RETURN_OBJECT">Se: readResolve メソッドの戻り値の型が Object で宣言されていない (SE_READ_RESOLVE_MUST_RETURN_OBJECT)</a></h3>


<p>
<code>readResolve</code> メソッドが直列化機構で認識されるためには戻り値の型が <code>Object</code> で宣言されなければなりません。 
</p>

    
<h3><a name="SE_TRANSIENT_FIELD_NOT_RESTORED">Se: 直列化復元によって設定されない transient フィールド  (SE_TRANSIENT_FIELD_NOT_RESTORED)</a></h3>


<p>
このクラスには複数の場所で更新されるフィールドがあります。したがって、このクラスの状態の一部であると思われます。
しかしながら、フィールドは transient と宣言しているので、 readObject/readResolve で値が設定されません。
クラスの直列化復元されたインスタンスにはデフォルト値が設定されます。
</p>

    
<h3><a name="SE_NO_SERIALVERSIONID">SnVI: Serializable なクラスが serialVersionUID を定義していない (SE_NO_SERIALVERSIONID)</a></h3>


<p>
このクラスは <code>Serializable</code> インタフェースを実装していますが、<code>serialVersionUID</code> フィールドを定義していません。
.class オブジェクトへの参照を追加するのと同じくらい簡単な変更でクラスに合成フィールドを追加します。
それは、残念ながら暗黙の <code>serialVersionUID</code> を変えます (たとえば、<code>String.class</code> への参照を追加すると、<code>class$java$lang$String</code> という static フィールドを生成します)。
また、バイトコードコンパイラへの異なるソースコードは、クラスオブジェクトまたは内部クラスに参照のために生成される合成変数のために異なる命名規則を使用するかもしれません。
バージョンを横断する Serializable の相互運用性を保証するために、明示的に、serialVersionUID を追加することを検討してください。
</p>

    
<h3><a name="UI_INHERITANCE_UNSAFE_GETRESOURCE">UI: クラスが拡張されるなら getResource の使い方は安全ではないかもしれない (UI_INHERITANCE_UNSAFE_GETRESOURCE)</a></h3>


<p>
このクラスが別のパッケージによって拡張されるなら、<code>this.getClass().getResource(...)</code> の呼び出しは予想外の結果をもたらす可能性があります。
</p>

    
<h3><a name="BC_IMPOSSIBLE_CAST">BC: 不可能なキャスト (BC_IMPOSSIBLE_CAST)</a></h3>


<p>
このキャストは、常に ClassCastException をスローします。
FindBugs は、instanceof チェックから型情報を調査して、メソッドからの戻り値とフィールドからロードされた値の型について、より多くの正確な情報を使用します。
したがって、宣言された変数の型にはより多くの正確な情報があるかもしれないしれません。
そして、キャストが常に実行時例外をスローするのか判定するために使用する可能性があります。
</p>

    
<h3><a name="BC_IMPOSSIBLE_DOWNCAST">BC: 不可能なダウンキャスト (BC_IMPOSSIBLE_DOWNCAST)</a></h3>


<p>
このキャストは、常に ClassCastException をスローします。
解析はキャストしている値の正確な型がわかっていると信じています。
そして、サブタイプへダウンキャストしようとする試みは、ClassCastException のスローによって常に失敗します。 
</p>

    
<h3><a name="BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY">BC: toArray メソッドの結果の不可能なダウンキャスト (BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY)</a></h3>


<p>
このコードは、以下のように、<code>Object[]</code> より特定の型のコレクションで <code>toArray</code> メソッドを呼び出す結果をキャストしています。
</p>
<blockquote><pre>
String[] getAsArray(Collection&lt;String&gt; c) {
  return (String[]) c.toArray();
}
</pre></blockquote>
<p>
これは通常、ClassCastException をスローして失敗します。
ほとんどすべてのコレクションの <code>toArray</code> メソッドは、<code>Object[]</code> を返します。
Collection オブジェクトは宣言された総称型コレクションの参照がないので、本当に何もできません。
コレクションから特定の型の配列を得る正しい方法は、<code>c.toArray(new String[]);</code> または <code>c.toArray(new String[c.size()]);</code> (後者はわずかにより効率的です) を使うことです。
これに対する1つの共通の知られている例外があります。
<code>Arrays.asList(...)</code>によって返されるリストの <code>toArray()</code> メソッドは、共変な配列を返します。
たとえば、<code>Arrays.asArray(new String[] { "a" }).toArray()</code> は <code>String []</code> を返します。
FindBugs はそのようなケースを検出して抑止しようとしますが、いくつか見落とすかもしれません。
</p>

    
<h3><a name="BC_IMPOSSIBLE_INSTANCEOF">BC: 常に false を返す instanceof (BC_IMPOSSIBLE_INSTANCEOF)</a></h3>


<p>
この instanceof は常に false を返します。これは安全で、誤解や論理エラーを指摘していないことを確認してください。
</p>

    
<h3><a name="BIT_ADD_OF_SIGNED_BYTE">BIT: 符号付きバイト値のビット加算 (BIT_ADD_OF_SIGNED_BYTE)</a></h3>


<p>
バイト値と明らかに下位8ビットがあるとわかっている値を加算しています。
ビット演算を実行する前にバイト配列からロードされた値は32ビットまで符号拡張されます。
したがって、<code>b[0]</code> の値が <code>0xff</code> で、<code>x</code> の初期値が <code>0</code> だとすると、
<code>((x &lt;&lt; 8) + b[0])</code> は、<code>0xff</code> が符号拡張で <code>0xffffffff</code> になるので、結果として <code>0xffffffff</code> が得られます。 
</p>
<p>
特に、バイト配列 int にパックする以下のようなコードはひどく間違っています。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i &lt; 4; i++) 
  result = ((result &lt;&lt; 8) + b[i]);
</pre></blockquote>
<p>
その代わりに以下のようなイディオムは動作します。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i &lt; 4; i++) 
  result = ((result &lt;&lt; 8) + (b[i] &amp; 0xff));
</pre></blockquote>

    
<h3><a name="BIT_AND">BIT: 互換性のないビットマスク (BIT_AND)</a></h3>


<p>
このメソッドは、<i>(e &amp; C)</i> 形式の式を <i>D</i> と比較しています。
定数 <i>C</i> と <i>D</i> の特定の値と常に等しくないことを比較します。論理エラーかタイプミスかもしれません。
</p>

    
<h3><a name="BIT_AND_ZZ">BIT: ((...) & 0) == 0 なのか確かめている (BIT_AND_ZZ)</a></h3>


<p>
このメソッドは、<i>(e &amp; 0)</i> 形式の式を0と比較しています。それは、常に等価であることを比較します。論理エラーかタイプミスかもしれません。
</p>

    
<h3><a name="BIT_IOR">BIT: 互換性のないビットマスク (BIT_IOR)</a></h3>


<p>
このメソッドは、<code>(e | C)</code> 形式の式を <code>D</code> と比較しています。
定数 <i>C</i> と <i>D</i> の特定の値と常に等しくないことを比較します。論理エラーかタイプミスかもしれません。
</p>
<p>
典型的に、このバグは、ビットセットで帰属関係のテストを実行したいコードで発生します。
しかし、ビット論理積演算子 ("&amp;") の代わりにビット論理和演算子 ("|") を使用しています。
</p>

    
<h3><a name="BIT_IOR_OF_SIGNED_BYTE">BIT: 符号付きバイト値のビット論理和 (BIT_IOR_OF_SIGNED_BYTE)</a></h3>


<p>
ロードしたバイト値 (たとえば、バイト配列からロードされた値や戻り値がバイト型のメソッドから返された値) とビット論理和を実行しています。
ビット演算を実行する前にバイト値は32ビットまで符号拡張されます。
したがって、<code>b[0]</code> の値が <code>0xff</code> で、<code>x</code> の初期値が <code>0</code> だとすると、
<code>((x &lt;&lt; 8) | b[0])</code> は、<code>0xff</code> が符号拡張で <code>0xffffffff</code> になるので、結果として <code>0xffffffff</code> が得られます。 
</p>
<p>
特に、バイト配列 int にパックする以下のようなコードはひどく間違っています。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i &lt; 4; i++) {
    result = ((result &lt;&lt; 8) | b[i]);
}
</pre></blockquote>
<p>
その代わりに以下のようなイディオムは動作します。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i &lt; 4; i++) {
    result = ((result &lt;&lt; 8) | (b[i] &amp; 0xff));
}
</pre></blockquote>

    
<h3><a name="BIT_SIGNED_CHECK_HIGH_BIT">BIT: ビット演算の符号をチェックする (BIT_SIGNED_CHECK_HIGH_BIT)</a></h3>


<p>
このメソッドは、<code>((event.detail &amp; SWT.SELECTED) &gt; 0)</code> のような式を比較しています。
ビット演算をより大きい演算子で比較することは、予想外の結果 (もちろん、<code>SWT.SELECTED</code> の値による) の原因になる可能性があります。
<code>SWT.SELECTED</code> が負数であるなら、これはバグの候補です。
<code>SWT.SELECTED</code> が負ではないとしても、'&gt; 0' の代わりに '!= 0' を使うことは良いプラクティスと思われます。
</p>
<p>
Boris Bokowski
</p>

    
<h3><a name="BOA_BADLY_OVERRIDDEN_ADAPTER">BOA: スーパークラスの Adapter で実装されるメソッドを誤ってオーバーライドしているクラス (BOA_BADLY_OVERRIDDEN_ADAPTER)</a></h3>


<p>
このメソッドは、スーパークラスで実装されているメソッドをオーバーライドしています。
スーパークラスは、java.awt.event や javax.swing.event パッケージで定義されているリスナを実装する Adapter です。
その結果、イベントが発生するときこのメソッドは呼び出されません。
</p>

    
<h3><a name="ICAST_BAD_SHIFT_AMOUNT">BSHIFT: 32ビット int の-31から31の範囲を超えた量によるシフト (ICAST_BAD_SHIFT_AMOUNT)</a></h3>


<p>
このコードは、32ビット int の-31から31の範囲を超えた量でシフトを実行しています。
これの効果は、どのくらいシフトするのかを決めるために整数値の下位5ビット (32で割った余り) を使うことです (たとえば、40ビットでシフトすることは8ビットでシフトすることと同じで、32ビットでシフトすることは0ビットでシフトすることと同じです)。
これは、おそらく期待されたことではなく、少なくとも紛らわしいです。
</p>

    
<h3><a name="BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR">Bx: プリミティブ値が3項演算子のためにアンボクシングされて、型変換される (BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR)</a></h3>


<p>
ラップされたプリミティブ値は、3項演算子 (<code> b ? e1 : e2</code>) の評価の一部として、別のプリミティブ型にアンボクシングされて変換されます。
Java 言語仕様では、<code>e1</code> と <code>e2</code> がラップされた数値なら値はアンボクシングされ、共通の型へと変換/型変換されます
(たとえば、<code>e1</code> が <code>Integer</code> で、<code>e2</code> が <code>Float</code> なら <code>e1</code> はアンボクシング (<code>int</code> に変換) され、<code>float</code> に変換され、ボクシング (<code>Float</code> に変換) されます)。
JLS セクション15.25を参照してください。
</p>

    
<h3><a name="CO_COMPARETO_RESULTS_MIN_VALUE">Co: compareTo()/compare() は Integer.MIN_VALUE を返す (CO_COMPARETO_RESULTS_MIN_VALUE)</a></h3>


<p>
いくつかの状況下では、この <code>compareTo</code> または <code>compare</code> メソッドは Integer.MIN_VALUE を返します。それは、非常に間違ったプラクティスです。
<code>compareTo</code> メソッドの戻り値で重要なことは結果の符号だけです。
しかし、結果の符号を無効にすることを期待して、<code>compareTo</code> メソッドの戻り値を無効にすることがあります。
戻り値が Integer.MIN_VALUE である場合を除き、Integer.MIN_VALUE よりも-1を返します。
</p>

    
<h3><a name="DLS_DEAD_LOCAL_INCREMENT_IN_RETURN">DLS: return 文に役に立たないインクリメントがある (DLS_DEAD_LOCAL_INCREMENT_IN_RETURN)</a></h3>


<p>
<code>return x++;</code> のような return 文があります。
接頭辞インクリメント/デクリメントは 式の値に影響を与えないので、インクリメント/デクリメントは効果がありません。
この文が正しいのか確かめてください。
</p>

    
<h3><a name="DLS_DEAD_STORE_OF_CLASS_LITERAL">DLS: クラスリテラルの無効な代入 (DLS_DEAD_STORE_OF_CLASS_LITERAL)</a></h3>


<p>
この命令は変数にクラスリテラルを代入していますが、決して使われません。<br>
<a href="//java.sun.com/j2se/1.5.0/compatibility.html#literal">The behavior of this differs in Java 1.4 and in Java 5</a><br>
J2SE 1.4 およびそれ以前のバージョンでは、<code>Foo.class</code> への参照は <code>Foo</code> のためのスタティックイニシャライザがすでに実行されていないなら実行することを強制します。
J2SE 5.0 ではそうしません。
</p>
<p>
より多くの詳細と例と J2SE 5.0 のクラスの強制的な初期化の方法の提案は Sun の <a href="//java.sun.com/j2se/1.5.0/compatibility.html#literal">article on Java SE compatibility</a> を参照してください。
</p>

    
<h3><a name="DLS_OVERWRITTEN_INCREMENT">DLS: 上書きされたインクリメント (DLS_OVERWRITTEN_INCREMENT)</a></h3>


<p>
このコードは、インクリメント演算 (たとえば、<code>i++</code>) を実行してすぐに上書きしています。
たとえば、<code>i = i++</code> は元の値をインクリメントした値で上書きします。 
</p>

    
<h3><a name="DMI_ARGUMENTS_WRONG_ORDER">DMI: 逆にされた引数 (DMI_ARGUMENTS_WRONG_ORDER)</a></h3>


<p>
このメソッド呼び出しへの引数は、順序が間違っているように見えます。
たとえば、呼び出し <code>Preconditions.checkNotNull("message", message)</code> は、引数を予約しました。チェックされる値は第一引数です。
</p>

    
<h3><a name="DMI_BAD_MONTH">DMI: 月のための間違った定数値 (DMI_BAD_MONTH)</a></h3>


<p>
このコードは、メソッドに0から11の範囲外の月定数値を渡しています。 
</p>

    
<h3><a name="DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE">DMI: 正確に表されない double から構築された BigDecimal (DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE)</a></h3>


<p>
このコードは、10進数の数にうまく変換されない double 値から BigDecimal を作成しています。
たとえば、Java で <code>new BigDecimal(0.1)</code> と書くと、0.1と正確に等しい BigDecimal (スケールが1でスケールなしの値が1) が作成されると思うかもしれませんが
実際には0.1000000000000000055511151231257827021181583404541015625と等しくなります。
</p>
<p>
おそらく <code>BigDecimal.valueOf(double d)</code> メソッドの使用が望ましいです。BigDecimal(たとえば、<code>BigDecimal.valueOf(0.1)</code> は0.1を与えます) を作成するためには double の文字列表現を使用します。
</p>

    
<h3><a name="DMI_CALLING_NEXT_FROM_HASNEXT">DMI: hasNext メソッドで next メソッドを呼び出している (DMI_CALLING_NEXT_FROM_HASNEXT)</a></h3>


<p>
<code>hasNext</code> メソッドは、<code>next</code> メソッドを呼び出しています。
<code>hasNext</code> メソッドは、イテレータの状態を変更することになっていないので、ほぼ確実に間違っています。
<code>next</code> メソッドがイテレータの状態を変更することになっています。
</p>

    
<h3><a name="DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES">DMI: コレクションは自分自身を含めるべきではない (DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES)</a></h3>


<p>
この総称型コレクションメソッドへの呼び出しはコレクションに自分自身が含まれている (たとえば、<code>s.contains(s)</code> が true だとして) 場合にだけ意味があります。
これは true である可能性が低くて、もし true なら問題の原因になります (たとえば、無限再帰になっているハッシュコードの計算)。
間違ったパラメータが渡されている可能性が高いです。
</p>

    
<h3><a name="DMI_DOH">DMI: D'oh! 無意味なメソッド呼び出し (DMI_DOH)</a></h3>


<p>
この部分的なメソッド呼び出しは、検査から明らかな理由で意味がありません。
</p>

    
<h3><a name="DMI_INVOKING_HASHCODE_ON_ARRAY">DMI: 配列で hashCode メソッドを呼び出している (DMI_INVOKING_HASHCODE_ON_ARRAY)</a></h3>


<p>
このコードは、配列で <code>hashCode</code> メソッドを呼び出しています。
配列で <code>hashCode</code> メソッドを呼び出すことは、System.identityHashCode と同じ値を返すので、コンテンツと配列の長さを無視します。
配列 <code>a</code> のコンテンツによるハッシュコードを必要とするなら、<code>java.util.Arrays.hashCode(a)</code> を使用してください。
</p>

    
<h3><a name="DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT">DMI: int に対して Double.longBitsToDouble() を呼び出している (DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT)</a></h3>


<p>
<code>Double.longBitsToDouble()</code> の呼び出しで、32ビット int 値が引数として渡されています。
これはほぼ間違いなく意図したことではありませんし意図した結果を与えることはほとんどありません。 
</p>

    
<h3><a name="DMI_VACUOUS_SELF_COLLECTION_CALL">DMI: コレクションへの無意味な呼び出し (DMI_VACUOUS_SELF_COLLECTION_CALL)</a></h3>


<p>
この呼び出しは意味がありません。
どんなコレクション <code>c</code> も <code>c.containsAll(c)</code> を呼び出すことは常に true であるべきです。
そして、<code>c.retainAll(c)</code> は効果があるはずがありません。
</p>

    
<h3><a name="DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION">Dm: ランタイムリテンションなしで、アノテーションの存在を調べるためにリフレクションを使用することはできない (DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION)</a></h3>


<p>
アノテーションは、<code>@Retention(RetentionPolicy.RUNTIME)</code> でアノテートされなければ、リフレクション (たとえば、<code>isAnnotationPresent(...)</code> メソッド) を使用して観測することができません。
</p>

    
<h3><a name="DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR">Dm: ScheduledThreadPoolExecutor の最大プールサイズを変えようとする無駄な試み (DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR)</a></h3>


<p>
<code>ScheduledThreadPoolExecutor</code> は <code>ThreadPoolExecutor</code> から継承されますが継承されたチューニングメソッドの一部は有効ではありません。
特に、corePoolSize スレッドとアンバウンド形式のキューを使用する固定サイズプールとして動作するので、maximumPoolSize の調整は有効な効果がありません。<br>
(<a href="http://java.sun.com/javase/ja/6/docs/ja/api/java/util/concurrent/ScheduledThreadPoolExecutor.html">Javadoc</a>)
</p>

    
<h3><a name="DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS">Dm: コアプールサイズが0の ScheduledThreadPoolExecutor の作成 (DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS)</a></h3>


<p>
コアプールサイズが0の <code>ScheduledThreadPoolExecutor</code> は決して何も実行しません。
最大プールサイズへの変更は無視されます。<br>
(<a href="http://java.sun.com/javase/ja/6/docs/ja/api/java/util/concurrent/ScheduledThreadPoolExecutor.html#ScheduledThreadPoolExecutor(int)">Javadoc</a>)
</p>

    
<h3><a name="DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD">Dm: EasyMock メソッドへの役に立たない/無意味な呼び出し (DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD)</a></h3>


<p>
この呼び出しは EasyMock メソッドにどんなオブジェクトも渡さないので何もしません。
</p>

    
<h3><a name="EC_ARRAY_AND_NONARRAY">EC: equals メソッドを使用して配列と非配列を比較している (EC_ARRAY_AND_NONARRAY)</a></h3>


<p>
このメソッドは、配列と配列であると思われない参照を比較するために <code>.equals(Object o)</code> を呼び出しています。
比較されているものが違う型なら不等であることが保証されているので、比較はほぼ間違いなく誤りです。
たとえそれらが両方とも配列であるとしても、配列の <code>equals</code> メソッドは2つの配列が同じオブジェクトであると決定するだけです。
配列のコンテンツを比較するためには <code>java.util.Arrays.equals(Object[], Object[])</code> を使用してください。 
</p>

    
<h3><a name="EC_BAD_ARRAY_COMPARE">EC: 配列の equals メソッド呼び出しは == と等価である (EC_BAD_ARRAY_COMPARE)</a></h3>


<p>
このメソッドは、配列で <code>.equals(Object o)</code> を呼び出しています。
配列は、<code>Object</code> の <code>equals</code> メソッドをオーバーライドしないので、配列で <code>equals</code> メソッドを呼び出すことはアドレスを比較することと同じです。
配列のコンテンツを比較するためには <code>java.util.Arrays.equals(Object[], Object[])</code> を使用してください。
配列のアドレスを比較するために、明示的に、<code>==</code> を使用して参照等価性をチェックすることは、それほど紛らわしくないでしょう。
</p>

    
<h3><a name="EC_INCOMPATIBLE_ARRAY_COMPARE">EC: equals(...) メソッドを使用して互換性のない配列を比較している (EC_INCOMPATIBLE_ARRAY_COMPARE)</a></h3>


<p>
このメソッドは、互換性のない型の配列を比較するために <code>.equals(Object o)</code> を呼び出しています (たとえば、<code>String[]</code> と <code>StringBuffer[]</code>、<code>String[]</code> と <code>int[]</code>) 。
それらは、決して等価ではありません。
さらに、<code>equals(...)</code> が配列を比較するのに使用されるとき、それらが同じ配列であるかどうか確かめるだけで、配列のコンテンツは無視します。
</p>

    
<h3><a name="EC_NULL_ARG">EC: equals(null) の呼び出し (EC_NULL_ARG)</a></h3>


<p>
このメソッドは、 null 値の引数を渡して <code>equals(Object)</code> を呼び出しています。
<code>equals</code> メソッドの規約によると、この呼び出しは常に false を返すはずです。
</p>

    
<h3><a name="EC_UNRELATED_CLASS_AND_INTERFACE">EC: equals メソッドを呼び出して無関係のクラスとインタフェースを比較している (EC_UNRELATED_CLASS_AND_INTERFACE)</a></h3>


<p>
このメソッドは、一方がクラスで他方がインタフェースである2つの参照で <code>equals(Object)</code> メソッドを呼び出しています。
クラスは、そのクラスの非抽象サブクラスも含めてインタフェースを実装していません。
したがって比較されている2つのオブジェクトは実行時に同じクラスのメンバである可能性が低いです (いくつかのアプリケーションクラスが解析できなかったか、動的クラスローディングが実行時に起こることができた場合を除く)。
<code>equals</code> メソッドの規約によると、異なるクラスのオブジェクトは常に不等として比較するべきです。
したがって、<code>java.lang.Object.equals(Object)</code> によって定義される規約によれば、この比較の結果は実行時に常に false になります。
</p>

    
<h3><a name="EC_UNRELATED_INTERFACES">EC: equals メソッドを呼び出して異なる型のインタフェースを比較している (EC_UNRELATED_INTERFACES)</a></h3>


<p>
このメソッドは、どちらも他方のサブタイプでない無関係なインタフェース型の2つの参照で <code>equals(Object)</code> メソッドを呼び出しています。
そして、両方のインタフェースを実装する既知の非抽象クラスがありません。
したがって比較されている2つのオブジェクトは実行時に同じクラスのメンバである可能性が低いです (いくつかのアプリケーションクラスが解析できなかったか、動的クラスローディングが実行時に起こることができた場合を除く)。
<code>equals</code> メソッドの規約によると、異なるクラスのオブジェクトは常に不等として比較するべきです。
したがって、<code>java.lang.Object.equals(Object)</code> によって定義される規約によれば、この比較の結果は実行時に常に false になります。
</p>

    
<h3><a name="EC_UNRELATED_TYPES">EC: equals メソッドを呼び出して異なる型を比較している (EC_UNRELATED_TYPES)</a></h3>


<p>
このメソッドは、共通のサブクラスがない異なるクラス型の2つのオブジェクト参照で <code>equals(Object)</code> メソッドを呼び出しています。
したがって比較されている2つのオブジェクトは実行時に同じクラスのメンバである可能性が低いです (いくつかのアプリケーションクラスが解析できなかったか、動的クラスローディングが実行時に起こることができた場合を除く)。
<code>equals</code> メソッドの規約によると、異なるクラスのオブジェクトは常に不等として比較するべきです。
したがって、<code>java.lang.Object.equals(Object)</code> によって定義される規約によれば、この比較の結果は実行時に常に false になります。
</p>

    
<h3><a name="EC_UNRELATED_TYPES_USING_POINTER_EQUALITY">EC: 参照等価性を使用して異なる型を比較している (EC_UNRELATED_TYPES_USING_POINTER_EQUALITY)</a></h3>


<p>
このメソッドは異なる型と思われる2つの参照を比較するために参照等価性を使用しています。
この比較の結果は、常に false です。
</p>

    
<h3><a name="EQ_ALWAYS_FALSE">Eq: equals メソッドは常に false を戻す (EQ_ALWAYS_FALSE)</a></h3>


<p>
このクラスでは、常に false を返す <code>equlas</code> メソッドを定義しています。
これは、オブジェクトがそれ自身と等価ではないことを意味していて、このクラスの有効な Map や Set を作成できません。
より根本的に、<code>equals</code> メソッドの要件の一つである反射性を満たしていないことになります。
</p>
<p>
おそらく意図されたことは、オブジェクトはそれ自身と等価であるというオブジェクト同一性です。
これは <code>Object</code> クラスから継承される振る舞いです。
異なるスーパークラスから継承される <code>equals</code> メソッドをオーバーライドする必要があるなら以下のようなコードが使えます。
</p>
<blockquote><pre>
public boolean equals(Object o) {
    return this == o;
}
</pre></blockquote>

    
<h3><a name="EQ_ALWAYS_TRUE">Eq: equals メソッドは常に true を返す (EQ_ALWAYS_TRUE)</a></h3>


<p>
このクラスは、常に true を返す <code>equals</code> メソッドを定義しています。
これは想像力に富むが、あまり良い方法とはいえません。さらに、<code>equals</code> メソッドが対称的ではないことを意味します。
</p>

    
<h3><a name="EQ_COMPARING_CLASS_NAMES">Eq: equals メソッドはクラスオブジェクトではなくクラス名を比較している (EQ_COMPARING_CLASS_NAMES)</a></h3>


<p>
このメソッドは、クラス名を比較することによって、2つのオブジェクトが同じクラスなのか確かめています。
異なるクラスローダによってロードされたクラスなら、同じ名前で異なるクラスがある可能性があります。
クラスオブジェクトが同じなのか確かめてください。
</p>

    
<h3><a name="EQ_DONT_DEFINE_EQUALS_FOR_ENUM">Eq: 列挙型は共変な equals メソッドを定義している (EQ_DONT_DEFINE_EQUALS_FOR_ENUM)</a></h3>


<p>
このクラスは列挙を定義していて、列挙の等価性はオブジェクト同一性を使用して定義されています。
列挙値のために共変な <code>equals</code> メソッドを定義することは、非常に間違ったプラクティスです。
2つの異なる列挙値が一般にの <code>equals</code> メソッドでは「等価ではない」と判定され、共変な <code>equals</code> メソッドでは「等価」と判定されるからです。
共変な <code>equals</code> メソッドを定義しないでください。
</p>

    
<h3><a name="EQ_OTHER_NO_OBJECT">Eq: equals(Object) メソッドをオーバーライドしていない equals メソッドの定義 (EQ_OTHER_NO_OBJECT)</a></h3>


<p>
このクラスは、<code>equals</code> メソッドを定義していますが、<code>java.lang.Object</code> クラスの <code>equals(Object)</code> メソッドをオーバーライドしていません。
その代わりに、スーパークラスから <code>equals(Object)</code> メソッドを継承して、<code>boolean equals(Object)</code> メソッドを定義するべきです。
</p>

    
<h3><a name="EQ_OTHER_USE_OBJECT">Eq: Object.equals(Object) をオーバーライドしていない equals メソッドの定義 (EQ_OTHER_USE_OBJECT)</a></h3>


<p>
このクラスは、<code>equals</code> メソッドを定義していますが、<code>java.lang.Object</code> クラスの <code>equals(Object)</code> メソッドをオーバーライドしていません。
クラスは、<code>boolean equals(Object)</code> メソッドを定義するべきです。
</p>

    
<h3><a name="EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC">Eq: equals メソッドはスーパークラスの equals メソッドをオーバーライドしているが、対称的ではないかもしれない (EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC)</a></h3>


<p>
このクラスはスーパークラスの <code>equals</code> メソッドをオーバーライドする <code>equals</code> メソッドを定義しています。
両方の <code>equals</code> メソッドは、2つのオブジェクトが等しいかどうかの判定で、<code>instanceof</code> を使用しています。
<code>equals</code> メソッドは対称的 (<code>a.equals(b) == b.equals(a)</code>) であることが重要なのでこれは危険を伴っています。
<i>B</i> が <i>A</i> のサブタイプなら <i>A</i> の <code>equals</code> メソッドは引数が <code>instanceof A</code> なのかチェックします。
そして、<i>B</i> の <code>equals</code> メソッドは引数が <code>instanceof B</code> なのかチェックします。
これらのメソッドによって定義された同値関係が対称的でないということです。
</p>

    
<h3><a name="EQ_SELF_USE_OBJECT">Eq: 共変な equals メソッドを定義して、Object.equals(Object) を継承している (EQ_SELF_USE_OBJECT)</a></h3>


<p>
このクラスは、共変な <code>equals</code> メソッドを定義していますが、 <code>equals(Object)</code> メソッドは <code>java.lang.Object</code> クラスから継承しています。
クラスは、<code>boolean equals(Object)</code> メソッドを定義するべきです。
</p>

    
<h3><a name="FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER">FE: NaN への等価性のための絶望的なテスト (FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER)</a></h3>


<p>
このコードは、浮動小数点が特別な非数値と等価であるか確かめています (たとえば <code>if (x == Double.NaN)</code>)。
しかしながら、<code>NaN</code> の特別な意味のため、値は <code>NaN</code> と等価ではありません。
したがって、<code>x == Double.NaN</code> は常に false と評価します。
<code>x</code> という値が特別な非数値であるかどうか確かめるためには <code>Double.isNaN(x)</code> を使用します (あるいは <code>x</code> が浮動小数点精度であるなら <code>Float.isNaN(x)</code>)。
</p>

    
<h3><a name="VA_FORMAT_STRING_BAD_ARGUMENT">FS: 書式指示子へ渡している引数に互換性がない (VA_FORMAT_STRING_BAD_ARGUMENT)</a></h3>


<p>
書式指示子は、対応する引数と互換性がありません。
たとえば、<code>System.out.println("%d\n", "hello");</code> の %d 書式指示子は数値の引数を必要としますが数値ではなく文字列が渡されています。
この文が実行されると実行時例外が発生します。
</p>

    
<h3><a name="VA_FORMAT_STRING_BAD_CONVERSION">FS: 与えられた引数の型は書式指示子に合致しません (VA_FORMAT_STRING_BAD_CONVERSION)</a></h3>


<p>
引数の1つは、対応する書式指示子と互換性がありません。その結果、実行されるときに実行時例外を生成します。
たとえば、<code>String.format("%d", "1")</code> は、文字列 "1" が書式指示子 "%d" と互換性がないので例外を生成します。
</p>

    
<h3><a name="VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED">FS: printf スタイルの書式が期待されているところで MessageFormat が与えられている (VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED)</a></h3>


<p>
Java の printf 書式文字列と引数のリストを期待するメソッドが呼び出されています。
しかしながら、書式文字列にはどんな書式指示子 (たとえば、%s) も含まないで、メッセージフォーマットの要素 (たとえば、{0}) を含んでいます。
printf スタイルの書式文字列が必要なときに、MessageFormat の文字列を与えている可能性が高いです。
実行時に、すべての引数は無視され、書式文字列は正確にフォーマットされずに返されます。
</p>

    
<h3><a name="VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED">FS: 書式文字列で実際に使われるより、多くの引数が渡されている (VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED)</a></h3>


<p>
可変長引数による書式文字列メソッドが呼び出されていますが書式文字列で実際に使われるより多くの引数が渡されています。
これは実行時例外の原因とはなりませんが、コードはフォーマットされた文字列に含まれることを意図した情報を黙って省略しているかもしれません。
</p>

    
<h3><a name="VA_FORMAT_STRING_ILLEGAL">FS: 無効な書式文字列 (VA_FORMAT_STRING_ILLEGAL)</a></h3>


<p>
書式文字列は構文的に無効です。この文が実行されると実行時例外が発生します。
</p>

    
<h3><a name="VA_FORMAT_STRING_MISSING_ARGUMENT">FS: 書式文字列は足りない引数を参照している (VA_FORMAT_STRING_MISSING_ARGUMENT)</a></h3>


<p>
書式文字列で書式指示子を満たすために十分な引数が渡されていません。この文が実行されると実行時例外が発生します。
</p>

    
<h3><a name="VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT">FS: 書式文字列ための前の引数がない (VA_FORMAT_STRING_NO_PREVIOUS_ARGUMENT)</a></h3>


<p>
この書式文字列は、前の書式指示子の引数が再利用されるようにするために「相対インデックス ("&lt;")」を指定しています。
しかしながら、前の引数がありません。
たとえば、<code>formatter.format("%&lt;s %s", "a", "b")</code> が実行されると MissingFormatArgumentException をスローします。
</p>

    
<h3><a name="GC_UNRELATED_TYPES">GC: 型パラメータとメソッド引数に関係がない (GC_UNRELATED_TYPES)</a></h3>


<p>
総称型コレクションメソッドへの呼び出しにコレクションのパラメータとは互換性のないクラスの引数があります (すなわち、引数の型は総称型引数に対応するスーパタイプでもサブタイプでもありません)。
したがって、コレクションにはここで使用されたメソッド引数と等価であるどんなオブジェクトも含まれていません。
多分間違った値がメソッドに渡されています。
一般に、2つの無関係なクラスのインスタンスは等価ではありません。
たとえば、<code>Foo</code> と <code>Bar</code> クラスがサブタイプによって関係がないなら、<code>Foo</code> のインスタンスは <code>Bar</code> のインスタンスと等価のはずがありません。
その他の問題で対称的ではない <code>equals</code> メソッドになる可能性が高いです。
たとえば、<code>Foo</code> が <code>String</code> と等価であるように <code>Foo</code> クラスを定義するなら、<code>String</code> は <code>String</code> だけと等価であるので、<code>equals</code> メソッドは対称的ではありません。
</p>
<p>
まれに、非対称 <code>equals</code> メソッドを定義して、まだ、何とかそれらのコードを機能させています。
APIのどれも文書化していないか、保証もしていないが、<code>Collection&lt;String&gt;</code> に <code>Foo</code> があるかどうか調べたいなら、
引数の <code>equals</code> メソッド (たとえば、<code>Foo</code>クラスの <code>equals</code> メソッド) を使用して等価性をチェックします。
</p>

    
<h3><a name="HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS">HE: ハッシュ化された文脈でハッシュ化できないクラスの使用がシグネチャで宣言されている (HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS)</a></h3>


<p>
メソッド、フィールド、クラスは、ハッシュ可能なクラスが必要な文脈で、ハッシュ化できないクラスが使用される総称的なシグネチャを宣言しています。
クラスは、<code>equals</code> メソッドを宣言していますが、<code>hashCode</code> メソッドは <code>java.lang.Object</code> から継承しています。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に従っていないのでハッシュ化できません。
</p>

    
<h3><a name="HE_USE_OF_UNHASHABLE_CLASS">HE: ハッシュデータ構造で hashCode メソッドのないクラスを使用している (HE_USE_OF_UNHASHABLE_CLASS)</a></h3>


<p>
このクラスは、<code>equals(Object)</code> メソッドを定義していますが、<code>hashCode</code> メソッドを定義していません。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に従っていません。
このクラスのインスタンスはハッシュデータ構造で使われています。最重要問題を修正する必要があります。
</p>

    
<h3><a name="ICAST_INT_2_LONG_AS_INSTANT">ICAST: int 値を long に変換して絶対時間として使用している (ICAST_INT_2_LONG_AS_INSTANT)</a></h3>


<p>
このコードは、32ビット int 値を64ビット long 値に変換して、絶対時間値を必要とするメソッドパラメータに渡しています。
絶対時間値は、「エポック」（すなわち、1970年1月1日、00:00:00 GMT）としてわかっている標準的な基準時間からのミリ秒数です。<br>
たとえば、次のメソッド（Date にエポックから秒を変換することを意図した）は、ひどく壊れています。
</p>
<blockquote><pre>
Date getDate(int seconds) { return new Date(seconds * 1000); }
</pre></blockquote>
<p>
乗算は32ビット演算を使用して、64ビット値に変換されます。
32ビット値は、64ビットに変換されて、絶対時間値を表すために使用されるとき、1969年12月と1970年1月の日付しか表せません。
</p>
<p>
上記のメソッドのための正しい実装は、以下のとおりです。
</p>
<blockquote><pre>
// 失敗、2037年後の日付
Date getDate(int seconds) { return new Date(seconds * 1000L); }

// より良い、すべての日付で動作する
Date getDate(long seconds) { return new Date(seconds * 1000); }
</pre></blockquote>

    
<h3><a name="ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL">ICAST: 整数値を double にキャストして Math.ceil() に渡している (ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL)</a></h3>


<p>
このコードは、整数値 (たとえば、int や long) を倍精度浮動小数点に変換してから、その結果を <code>Math.ceil()</code> に渡しています。
整数を double に変換すると小数部がない数値が得られるので、この演算は常にノーオペレーションになります。
<code>Math.ceil()</code>に渡される値を生成した演算が倍精度浮動小数点演算を使用して実行することを意図した可能性が高いです。
</p>

    
<h3><a name="ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND">ICAST: 整数値を float にキャストして Math.round() に渡している (ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND)</a></h3>


<p>
このコードは、整数値を float 精度浮動小数点に変換してから、その結果を <code>Math.round()</code> に渡して引数に最も近い int/long を返します。
整数を float に変換すると小数部がない数値が得られるので、この演算は常にノーオペレーションになります。
<code>Math.round()</code>に渡される値を生成した演算が浮動小数点演算を使用して実行することを意図した可能性が高いです。
</p>

    
<h3><a name="IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD">IJU: run メソッドでの JUnit アサーションは JUnit によって通知されない (IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD)</a></h3>


<p>
<code>run</code> メソッドで JUnit アサーションが実行されています。失敗した JUnit アサーションは例外をスローします。
したがって、この例外がテストメソッドを実行したスレッド以外のスレッドで発生するなら、例外はスレッドを終了させますが、テストの失敗になりません。 
</p>

    
<h3><a name="IJU_BAD_SUITE_METHOD">IJU: TestCase は suite メソッドの間違った宣言をしている (IJU_BAD_SUITE_METHOD)</a></h3>


<p>
JUnit の TestCase クラスで、<code>suite</code> メソッドを実装しています。
しかしながら、<code>suite</code> メソッドは、
</p>
<blockquote><pre>
public static junit.framework.Test suite()
</pre></blockquote>
<p>か</p>
<blockquote><pre>
public static junit.framework.TestSuite suite()
</pre></blockquote>
<p>
のどちらかを宣言する必要があります。
</p>

    
<h3><a name="IJU_NO_TESTS">IJU: TestCase はテストがない  (IJU_NO_TESTS)</a></h3>


<p>
JUnit の TestCase クラスで、どんなテストメソッドも実装していません。
</p>

    
<h3><a name="IJU_SETUP_NO_SUPER">IJU: TestCase は super.setup() を呼び出さない setUp メソッドを実装している (IJU_SETUP_NO_SUPER)</a></h3>


<p>
JUnit の TestCase クラスで、<code>setUp</code> メソッドを実装しています。
<code>setUp</code> メソッドは、<code>super.setUp()</code> を呼び出すべきなのにそうしていません。
</p>

    
<h3><a name="IJU_SUITE_NOT_STATIC">IJU: TestCase は 非 static な suite メソッドを実装している (IJU_SUITE_NOT_STATIC)</a></h3>


<p>
JUnit の TestCase クラスで、<code>suite</code> メソッドを実装しています。
<code>suite</code> メソッドは static として宣言するべきなのにそうしていません。
</p>

    
<h3><a name="IJU_TEARDOWN_NO_SUPER">IJU: TestCase は super.tearDown() を呼び出さない tearDown メソッドを実装している  (IJU_TEARDOWN_NO_SUPER)</a></h3>


<p>
JUnit の TestCase クラスで、<code>tearDown</code> メソッドを実装しています。
<code>tearDown</code> メソッドは、<code>super.tearDown()</code> を呼び出すべきなのにそうしていません。
 </p>

    
<h3><a name="IL_CONTAINER_ADDED_TO_ITSELF">IL: コレクションは自分自身を追加している (IL_CONTAINER_ADDED_TO_ITSELF)</a></h3>


<p>
コレクションは、自分自身を追加しています。その結果、hashCode を計算すると <code>StackOverflowException</code> をスローします。
</p>

    
<h3><a name="IL_INFINITE_LOOP">IL: 明らかな無限ループ (IL_INFINITE_LOOP)</a></h3>


<p>
このループは、例外をスローする以外の方法で終了させることができないように思われます。
</p>

    
<h3><a name="IL_INFINITE_RECURSIVE_LOOP">IL: 明らかな無限再帰ループ (IL_INFINITE_RECURSIVE_LOOP)</a></h3>


<p>
このメソッドは、無条件で自分自身を呼び出します。これは、スタックオーバーフローになる無限再帰ループを示しています。
</p>

    
<h3><a name="IM_MULTIPLYING_RESULT_OF_IREM">IM: 整数剰余の結果の整数乗算 (IM_MULTIPLYING_RESULT_OF_IREM)</a></h3>


<p>
このコードは、整数剰余の結果に整数定数を乗算しています。
紛らわしい演算子の優先順位がないことを確実にしてください。
たとえば、i % 60 * 1000 は、i % (60 * 1000) ではなく (i % 60) * 1000 となります。 
</p>

    
<h3><a name="INT_BAD_COMPARISON_WITH_INT_VALUE">INT: int 値と long 定数との間違った比較 (INT_BAD_COMPARISON_WITH_INT_VALUE)</a></h3>


<p>
このコードは、int 値と int 値として表現できる値の範囲外にある long 定数を比較しています。
この比較は無意味で、おそらく間違っています。
</p>

    
<h3><a name="INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE">INT: 負でない値と負の定数との間違った比較 (INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE)</a></h3>


<p>
このコードは、負でないことが保証されている値と負の定数とを比較しています。 
</p>

    
<h3><a name="INT_BAD_COMPARISON_WITH_SIGNED_BYTE">INT: 符号付きバイトの間違った比較 (INT_BAD_COMPARISON_WITH_SIGNED_BYTE)</a></h3>


<p>
符号付バイトのとりうる値の範囲は-128～127です。その範囲外で符号付バイトを値と比較することは無意味で間違っていそうです。
符号付きバイト <code>b</code> を範囲が0～255の符号なしバイトに変換するには <code>0xff &amp; b</code> を使用してください。 
</p>

    
<h3><a name="IO_APPENDING_TO_OBJECT_OUTPUT_STREAM">IO: オブジェクト出力ストリームへの追加は失敗に終わる (IO_APPENDING_TO_OBJECT_OUTPUT_STREAM)</a></h3>


<p>
このコードは、ファイルを追加モードで開いて、オブジェクト出力ストリームの中で結果をラップしています。
これは、ファイルに格納された既存のオブジェクト出力ストリームに追加できないでしょう。
オブジェクト出力ストリームに追加したいなら、オブジェクト出力ストリームを開いておく必要があります。
</p>
<p>
追加モードでファイルを開き、オブジェクト出力ストリームで書き込むことができる唯一の状況は、
ファイルを読み出すときにランダムアクセスモードで開き、追加を開始するところまでバイトオフセットをシークすると計画した場合です。
</p> 

    
<h3><a name="IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN">IP: メソッドで読み取られずに上書きされているパラメータ (IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN)</a></h3>


<p>
このパラメータの初期値は無視され、ここで上書きされています。
これは多くの場合、パラメータへの書き込みが呼び出し元に戻されるという誤った考えを示しています。 
</p>

    
<h3><a name="MF_CLASS_MASKS_FIELD">MF: スーパークラスのフィールドを隠すフィールドを定義しているクラス (MF_CLASS_MASKS_FIELD)</a></h3>


<p>
このクラスは、スーパークラスの可視インスタンスフィールドと同じ名前でフィールドを定義しています。
これは紛らわしくて、メソッドがフィールドを更新するかアクセスするなら、間違いを指摘するかもしれません。
</p>

    
<h3><a name="MF_METHOD_MASKS_FIELD">MF: フィールドを隠す変数を定義しているメソッド (MF_METHOD_MASKS_FIELD)</a></h3>


<p>
このメソッドは、このクラスまたはスーパークラスのフィールドと同じ名前でローカル変数を定義しています。
これはフィールドから初期化されていない値を読み出したり初期化されていないフィールドをそのままにしておくメソッドの原因になるかもしれません。
</p>

    
<h3><a name="NP_ALWAYS_NULL">NP: null 値を利用している (NP_ALWAYS_NULL)</a></h3>


<p>
ここで null 値を利用しようとしています。
コードが実行されると NullPointerException が発生します。
</p>

    
<h3><a name="NP_ALWAYS_NULL_EXCEPTION">NP: null 値を例外経路で利用している (NP_ALWAYS_NULL_EXCEPTION)</a></h3>


<p>
例外経路上のここで null 値を利用しています。コードが実行されると NullPointerException が発生します。
現在の FindBugs は実行不可能な例外経路を取り除いていないので、誤検出かもしれないことに注意してください。
</p>
<p>
switch 文の default が多くの場合実行不可能なので FindBugs が例外経路である default を検討することに注意して下さい。
</p>

    
<h3><a name="NP_ARGUMENT_MIGHT_BE_NULL">NP: null の引数をチェックしていないメソッド (NP_ARGUMENT_MIGHT_BE_NULL)</a></h3>


<p>
このメソッドへのパラメータが null かどうか確かめるために常にチェックされるべき値として特定されました。
しかし、null チェックをしないで、null 値が利用されています。
</p>

    
<h3><a name="NP_CLOSING_NULL">NP: 常に null 値のオブジェクトで close メソッドを呼び出している (NP_CLOSING_NULL)</a></h3>


<p>
<code>close</code> メソッドは、常に null 値のオブジェクトで呼び出されています。
この文が実行されるなら NullPointerException が発生します。
ここでクローズするべき何かを決してクローズしないという大きな危険性があります。
</p>

    
<h3><a name="NP_GUARANTEED_DEREF">NP: null 値を利用することが保証されている (NP_GUARANTEED_DEREF)</a></h3>


<p>
文または分岐が実行されるなら、この時点で値は null であり、null 値を利用する (フォワードパスで実行時例外を伴うこと以外は) ことが保証されています。
</p>
<p>
なお、<code>if (x == null) throw new NullPointerException();</code> は <code>x</code> の参照解除として扱われることに注意して下さい。
</p>

    
<h3><a name="NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH">NP: null 値を例外経路で利用することが保証されている (NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH)</a></h3>


<p>
例外経路上の文または分岐が実行されるなら、この時点で値は null であり、null 値を利用する (フォワードパスで実行時例外を伴うこと以外は) ことが保証されています。
</p>

    
<h3><a name="NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">NP: 非 null フィールドは初期化されていない (NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)</a></h3>


<p>
フィールドは、非 null としてマークされていますが、コンストラクタで書き込まれていません。
フィールドは、コンストラクタの間、ほかの場所で初期化されるか、または使用する前に常に初期化されるかもしれません。
</p>

       
<h3><a name="NP_NONNULL_PARAM_VIOLATION">NP: メソッド呼び出しは非 null パラメータに対して null を渡している (NP_NONNULL_PARAM_VIOLATION)</a></h3>


<p>
このメソッドは、非 null でなければならないメソッドのパラメータとして、null 値を渡しています。
このパラメータは、@Nonnull として明示的にアノテートされていたか、または解析が常に null 値を利用すると示していました。
</p>

    
<h3><a name="NP_NONNULL_RETURN_VIOLATION">NP: null を返すかもしれないメソッドが @NonNull 宣言されている (NP_NONNULL_RETURN_VIOLATION)</a></h3>


<p>
このメソッドは、null 値を返すかもしれないのにメソッド (またはスーパークラスのメソッド) の戻り値に @NonNull が宣言されています。
</p>

    
<h3><a name="NP_NULL_INSTANCEOF">NP: null とわかっている値をその型のインスタンスなのか確かめている (NP_NULL_INSTANCEOF)</a></h3>


<p>
チェックされている値が null であることが保証されているので、instanceof は常に faluse を返します。
これは安全で、誤解や論理エラーを指摘していないことを確認してください。
</p>

    
<h3><a name="NP_NULL_ON_SOME_PATH">NP: null 値を利用している可能性がある (NP_NULL_ON_SOME_PATH)</a></h3>


<p>
そこで分岐または文が実行されるなら null 値が利用されて NullPointerException が発生します。
もちろん、問題は分岐または文が実行不可能で、NullPointerException が決して発生する可能性がないということかもしれません。
それを決めるのは FindBugs の能力を超えています。
</p>

    
<h3><a name="NP_NULL_ON_SOME_PATH_EXCEPTION">NP: null 値を例外経路で利用している可能性がある (NP_NULL_ON_SOME_PATH_EXCEPTION)</a></h3>


<p>
例外経路上のここで null 値が利用されています。コードが実行されると NullPointerException が発生するかもしれません。
現在の FindBugs は実行不可能な例外経路を取り除かないので、誤検出かもしれないことに注意してください。
</p>
<p>
switch 文の default が多くの場合実行不可能なので FindBugs が例外経路である default を検討することに注意して下さい。
</p>

    
<h3><a name="NP_NULL_PARAM_DEREF">NP: メソッド呼び出しは非 null パラメータに対して null を渡している (NP_NULL_PARAM_DEREF)</a></h3>


<p>
このメソッド呼び出しは非 null メソッドパラメータに対して null 値を渡しています。
パラメータは、常に非 null とすべきパラメータとしてアノテートされていたか、または解析が常に null 値を利用すると示していました。
</p>

    
<h3><a name="NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS">NP: メソッド呼び出しは非 null パラメータに対して null を渡している (NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS)</a></h3>


<p>
すべての既知のターゲットメソッドが非 null であることをパラメータに要求する呼び出し場所で、おそらく null 値を渡しています。
パラメータは、常に非 null とすべきパラメータとしてアノテートされていたか、または解析が常に null 値を利用すると示していました。
</p>

    
<h3><a name="NP_NULL_PARAM_DEREF_NONVIRTUAL">NP: 非 null パラメータに null を渡している非仮想メソッドの呼び出し (NP_NULL_PARAM_DEREF_NONVIRTUAL)</a></h3>


<p>
null の可能性がある値が、非 null メソッドパラメータに渡されています。
パラメータは、常に非 null とすべきパラメータとしてアノテートされていたか、または解析が常に null 値を利用すると示していました。
</p>

    
<h3><a name="NP_OPTIONAL_RETURN_NULL">NP: Optional の戻り型を持つメソッドが明示的に null を返す (NP_OPTIONAL_RETURN_NULL)</a></h3>


<p>
Optional の戻り型の使い方は、常に明示的に null を返すのは設計が望ましくないことを意味します。
null 値をこのようなケースで返すことは契約違反で、多分クライアントコードを破壊するでしょう。
</p>

    
<h3><a name="NP_STORE_INTO_NONNULL_FIELD">NP: @NonNull でアノテートされたフィールドに null を格納している (NP_STORE_INTO_NONNULL_FIELD)</a></h3>


<p>
@NonNull でアノテートされたフィールドに null かもしれない値を格納しています。 
</p>

    
<h3><a name="NP_UNWRITTEN_FIELD">NP: 書き込まれていないフィールドの読み出し (NP_UNWRITTEN_FIELD)</a></h3>


<p>
プログラムは、決して null でない値を書き込むとは思われないフィールドの値を利用しています。
この値を利用すると NullPointerException が発生します。
</p>

    
<h3><a name="NM_BAD_EQUAL">Nm: クラスは equal(Object) を定義しています。equals(Object) にすべきですか? (NM_BAD_EQUAL)</a></h3>


<p>
このクラスは、<code>equal(Object)</code> という名前のメソッドを定義しています。
このメソッドは、<code>java.lang.Object</code> の <code>equals(Object)</code> を (おそらく意図的に) オーバーライドしていません。
</p>

    
<h3><a name="NM_LCASE_HASHCODE">Nm: クラスは hashcode() を定義しています。hashCode() にすべきですか? (NM_LCASE_HASHCODE)</a></h3>


<p>
このクラスは、<code>hashcode()</code> という名前のメソッドを定義しています。
このメソッドは、<code>java.lang.Object</code> の <code>hashCode</code> メソッドを (おそらく意図的に) オーバーライドしていません。
</p>

    
<h3><a name="NM_LCASE_TOSTRING">Nm: クラスは tostring() を定義しています。toString() にすべきですか? (NM_LCASE_TOSTRING)</a></h3>


<p>
このクラスは、<code>tostring()</code> という名前のメソッドを定義しています。
このメソッドは、<code>java.lang.Object</code> の <code>toString</code> メソッドを (おそらく意図的に) オーバーライドしていません。
</p>

    
<h3><a name="NM_METHOD_CONSTRUCTOR_CONFUSION">Nm: 明らかなメソッドとコンストラクタの混乱 (NM_METHOD_CONSTRUCTOR_CONFUSION)</a></h3>


<p>
この正規のメソッドは定義しているクラスと同じ名前です。
これはコンストラクタを意図していた可能性が高いです。もしそうなら void 戻り値の宣言を除去してください。
このメソッドを定義したことが偶然間違っているとわかり、正しいコンストラクタを定義したが、下位互換性のためにこのメソッドを取り除くことができないなら、メソッドを非推奨にしてください。
</p>

    
<h3><a name="NM_VERY_CONFUSING">Nm: 非常に紛らわしい名前のメソッド (NM_VERY_CONFUSING)</a></h3>


<p>
参照されたメソッドは、大文字の使い方だけによって異なる名前があります。
大文字の使い方が同一ならメソッドの1つが他のメソッドをオーバーライドするので、非常に紛らわしいです。
</p>

    
<h3><a name="NM_WRONG_PACKAGE">Nm: パラメータの間違ったパッケージのために、スーパークラスのメソッドをオーバーライドしていないメソッド (NM_WRONG_PACKAGE)</a></h3>


<p>
パラメータの型がスーパークラスで対応するパラメータの型と正確に合致していないので、サブクラスのメソッドはスーパークラスの類似したメソッドをオーバーライドしていません。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
import alpha.Foo;

public class A {
    public int f(Foo x) { return 17; }
}
----
import beta.Foo;

public class B extends A {
    public int f(Foo x) { return 42; }
}
</pre></blockquote>
<p>
クラス <code>B</code> で定義された <code>f(Foo)</code> メソッドは、クラス <code>A</code> の <code>f(Foo)</code> メソッドをオーバーライドしていません。
これは引数の型 <code>Foo</code> が違うパッケージだからです。
</p>

    
<h3><a name="QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">QBA: 論理式で boolean リテラル値を代入しているメソッド (QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT)</a></h3>


<p>
このメソッドは、if または while の式の中の boolean 変数に boolean リテラル値 (true または false) を代入しています。
おそらく、これは = による代入ではなく、== を使用して論理比較をすることになっていました。
</p>

    
<h3><a name="RC_REF_COMPARISON">RC: 疑わしい参照比較 (RC_REF_COMPARISON)</a></h3>


<p>
このメソッドは、 == または != 演算子を使用して2つの参照値を比較しています。
この型のインスタンスを比較する正しい方法は、一般に <code>equals</code> メソッドです。
等価で識別可能なインスタンスを作成する可能性がありますが異なるオブジェクトなので == で比較しないでください。
参照によって一般に比較されるべきでないクラスの例は、<code>java.lang.Integer</code> 、<code>java.lang.Float</code> などです。
</p>

    
<h3><a name="RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE">RCN: すでに利用していた値の null チェック (RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE)</a></h3>


<p>
ここで値が null なのかチェックしていますが、すでに値を利用していたので null である可能性はありません。
値が null なら以前の利用で NullPointerException が発生していたでしょう。
基本的に、値が null であることを許すのかどうかに関係なく、このコードと以前の値の利用は一致しません。
チェックは冗長か、または以前の値の利用は誤りです。
</p>

    
<h3><a name="RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">RE: 正規表現のための無効な構文 (RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION)</a></h3>


<p>
このコードは、正規表現の構文によると無効である正規表現を使用しています。
この文が実行されるとき PatternSyntaxException をスローします。 
</p>

    
<h3><a name="RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION">RE: 正規表現のために使われている File.separator (RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION)</a></h3>


<p>
このコードは、正規表現が必要とされる場所で、<code>File.separator</code> を使用しています。
これは <code>File.separator</code> がバックスラッシュである Windows プラットホームでは失敗します。
バックスラッシュは正規表現ではエスケープ文字として解釈されます。
その他の選択肢としては、<code>File.separator</code> の代わりに <code>File.separatorChar=='\\' ? "\\\\" : File.separator</code> を使用できます。 
</p>

    
<h3><a name="RE_POSSIBLE_UNINTENDED_PATTERN">RE: 正規表現のために使われている "." または "|" (RE_POSSIBLE_UNINTENDED_PATTERN)</a></h3>


<p>
String 機能が呼び出されていて、"." または "|" が引数として正規表現を取るパラメータに渡されています。
これは、意図したことですか?
たとえば
</p>
<ul>
  <li><code>s.replaceAll(".", "/")</code> は、すべての文字が '/' 文字に置換された String を返す</li>
  <li><code>s.split(".")</code> は、常に長さが0の String 配列を返す</li>
  <li><code>"ab|cd".replaceAll("|", "/")</code> は、<code>"/a/b/|/c/d/"</code> を返す</li>
  <li><code>"ab|cd".split("|")</code> は、6個の要素がある配列を返す: <code>[, a, b, |, c, d]</code></li>
</ul>

    
<h3><a name="RV_01_TO_INT">RV: 0から1の乱数値は整数値0に丸められる (RV_01_TO_INT)</a></h3>


<p>
0から1の乱数値は整数値0に丸められます。
おそらく整数に丸められる前に何か他のことによって乱数値を倍数にしたかったか、または <code>Random.nextInt(n)</code> メソッドを使いたかったのでしょう。
</p>

    
<h3><a name="RV_ABSOLUTE_VALUE_OF_HASHCODE">RV: 符号付き32ビットハッシュコードの絶対値を計算する間違った試み (RV_ABSOLUTE_VALUE_OF_HASHCODE)</a></h3>


<p>
このコードは、ハッシュコードを生成して絶対値を計算しています。
ハッシュコードが <code>Integer.MIN_VALUE</code> なら結果は同様に負です (<code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code> なので)。
</p>
<p>
文字列の2^32個に1個は <code>Integer.MIN_VALUE</code> のハッシュコードを持っていて、「polygenelubricants」、「GydZG_」、「DESIGNING WORKHOUSES」が該当します。
</p>

    
<h3><a name="RV_ABSOLUTE_VALUE_OF_RANDOM_INT">RV: 符号付き整数の乱数の絶対値を計算する間違った試み (RV_ABSOLUTE_VALUE_OF_RANDOM_INT)</a></h3>


<p>
このコードは、符号付き整数の乱数を生成して絶対値を計算しています。
乱数ジェネレータで返される数が <code>Integer.MIN_VALUE</code> なら結果は同様に負です (<code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code> なので)。 
(同じ問題は long 値でも同様に起きます)。
</p>

    
<h3><a name="RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE">RV: compareTo によって返された特定の値のコードチェック (RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE)</a></h3>


<p>
このコードは、compareTo または compare メソッドを呼び出して、戻り値が特定の値（たとえば1または-1） なのか確かめています。
これらのメソッドを呼び出すときは特定のゼロ以外の値ではなく、結果の符号だけをチェックするべきです。
多数または大部分の compareTo と比較メソッドは-1、0または1を返しますが、いくつかは他の値を返します。
</p>

    
<h3><a name="RV_EXCEPTION_NOT_THROWN">RV: 作成した例外をスローするのではなく捨てている (RV_EXCEPTION_NOT_THROWN)</a></h3>


<p>
このコードは、例外 (またはエラー) オブジェクトを作成していますが、何もしていません。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
if (x &lt; 0) {
    new IllegalArgumentException("x must be nonnegative");
}
</pre></blockquote>
<p>
おそらくプログラマの意図は、作成した例外をスローすることでした。 
</p>
<blockquote><pre>
if (x &lt; 0) {
    throw new IllegalArgumentException("x must be nonnegative");
}
</pre></blockquote>

    
<h3><a name="RV_RETURN_VALUE_IGNORED">RV: 戻り値を無視しているメソッド (RV_RETURN_VALUE_IGNORED)</a></h3>


<p>
このメソッドの戻り値はチェックするべきです。
この警告の共通の原因は、オブジェクトが更新されると思って不変オブジェクトのメソッドを呼び出すことです。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
String dateString = getHeaderField(name);
dateString.trim();
</pre></blockquote>
<p>
プログラマは、<code>trim</code> メソッドが <code>dateString</code> によって参照される String オブジェクトが更新されると思っています。
しかし、String オブジェクトは不変で、<code>trim</code> メソッドが新しい String オブジェクトを返すのに無視しています。
このコードは、以下のように修正するべきです。
</p>
<blockquote><pre>
String dateString = getHeaderField(name);
dateString = dateString.trim();
</pre></blockquote>

    
<h3><a name="RpC_REPEATED_CONDITIONAL_TEST">RpC: 条件テストの繰り返し (RpC_REPEATED_CONDITIONAL_TEST)</a></h3>


<p>
このコードには条件テストが2回、つまり、1つめの条件テストが正しいとき、2つめの条件テストが実行されます (たとえば、<code>x == 0 || x == 0</code>)。
多分、2つめの条件テストは何か他のことを意図しています (たとえば、<code>x == 0 || y == 0</code>)。
</p>

    
<h3><a name="SA_FIELD_SELF_ASSIGNMENT">SA: フィールドの自己代入 (SA_FIELD_SELF_ASSIGNMENT)</a></h3>


<p>
このメソッドにはフィールドの自己代入があります。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
int x;
public void foo() {
    x = x;
}
</pre></blockquote>
<p>
そのような代入は役に立たないので、論理エラーかタイプミスかもしれません。
</p>

    
<h3><a name="SA_FIELD_SELF_COMPARISON">SA: フィールドとそれ自身との自己比較 (SA_FIELD_SELF_COMPARISON)</a></h3>


<p>
このメソッドは、フィールドをそれ自身と比較しています。
論理エラーかタイプミスかもしれません。正しいものを比較していることを確認してください。 
</p>

    
<h3><a name="SA_FIELD_SELF_COMPUTATION">SA: フィールドの無意味な自己演算 (たとえば、 x & x) (SA_FIELD_SELF_COMPUTATION)</a></h3>


<p>
このメソッドは、フィールドと同じフィールドへの別の参照との無意味な計算を実行しています (たとえば、x &amp; x または x - x)。
この計算の性質のため、演算は意味をなすとは思われないので、論理エラーかタイプミスかもしれません。
計算をチェックしてください。
</p>

    
<h3><a name="SA_LOCAL_SELF_ASSIGNMENT_INSTEAD_OF_FIELD">SA: フィールドへの代入ではなくローカル変数への自己代入 (SA_LOCAL_SELF_ASSIGNMENT_INSTEAD_OF_FIELD)</a></h3>


<p>
このメソッドにはローカル変数の自己代入があり、ローカル変数とフィールドが同じ名前です。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
    int foo;
    public void setFoo(int foo) {
        foo = foo;
    }
</pre></blockquote>
<p>
そのような代入は役に立ちません。そうではなく、フィールドに代入するつもりでしたか？
</p>

    
<h3><a name="SA_LOCAL_SELF_COMPARISON">SA: ローカル変数とそれ自身との自己比較 (SA_LOCAL_SELF_COMPARISON)</a></h3>


<p>
このメソッドは、ローカル変数をそれ自身と比較しています。論理エラーかタイプミスかもしれません。
正しいものを比較していることを確認してください。 
</p>

    
<h3><a name="SA_LOCAL_SELF_COMPUTATION">SA: 変数の無意味な自己演算 (たとえば、x & x) (SA_LOCAL_SELF_COMPUTATION)</a></h3>


<p>
このメソッドは、ローカル変数と同じ変数への別の参照との無意味な計算を実行しています (たとえば、x &amp; x または x - x)。
この計算の性質のため、演算は意味をなすとは思われないので、論理エラーかタイプミスかもしれません。
計算をダブルチェックしてください。 
</p>

    
<h3><a name="SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH">SF: switch 文のフォールスルーのために格納が無効になっている (SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH)</a></h3>


<p>
前の case で格納された値が switch 文のフォールスルーのためにここで上書きされています。
前の case の終わりに break または return を入れるのを忘れた可能性があります。 
</p>

    
<h3><a name="SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW">SF: スローする switch 文のフォールスルーのために格納が無効になっている (SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW)</a></h3>


<p>
前の case で格納された値が例外がスローされる場所で、switch 文のフォールスルーのためにここで失われています。
前の case の終わりに break または return を入れるのを忘れた可能性があります。
</p>

    
<h3><a name="SIC_THREADLOCAL_DEADLY_EMBRACE">SIC: 非 static 内部クラスとスレッドローカルのデッドロック (SIC_THREADLOCAL_DEADLY_EMBRACE)</a></h3>


<p>
このクラスは内部クラスですが、おそらく static 内部クラスにすべきです。
実際には内部クラスと外部クラスのスレッドローカルとの間にデッドロックの深刻な危険性があります。
内部クラスが static でないので、外部クラスへの参照を保持します。
スレッドローカルに内部クラスのインスタンスの参照があるなら、内部と外部のインスタンスの両方が到達可能になり、ガベージされません。
</p>

    
<h3><a name="SIO_SUPERFLUOUS_INSTANCEOF">SIO: instanceof 演算子を使用した不必要な型チェック (SIO_SUPERFLUOUS_INSTANCEOF)</a></h3>


<p>
オブジェクトが要求する型であるかどうかにかかわらず、静的に確定している可能性があるのに instanceof 演算子を使用して型チェックをしています。
</p>

    
<h3><a name="SQL_BAD_PREPARED_STATEMENT_ACCESS">SQL: インデックスが0で PreparedStatement にアクセスしようとしているメソッド (SQL_BAD_PREPARED_STATEMENT_ACCESS)</a></h3>


<p>
インデックスが0で、<code>PreparedStatement</code> の setXXX メソッドを呼び出しています。
インデックスは1から開始するので、これは常に間違いです。
</p>

    
<h3><a name="SQL_BAD_RESULTSET_ACCESS">SQL: インデックスが0で ResultSet にアクセスしようとしているメソッド (SQL_BAD_RESULTSET_ACCESS)</a></h3>


<p>
インデックスが0で、<code>ResultSet</code> の getXXX、updateXXX メソッドを呼び出しています。
<code>ResultSet</code> のインデックスは1から開始するので、これは常に間違いです。
</p>

    
<h3><a name="STI_INTERRUPTED_ON_CURRENTTHREAD">STI: interrupted メソッドを呼び出すために不要な currentThread メソッドを呼び出している (STI_INTERRUPTED_ON_CURRENTTHREAD)</a></h3>


<p>
このメソッドは、<code>interrupted</code> メソッドを呼び出すために <code>Thread.currentThread()</code> を呼び出しています。
<code>interrupted</code> メソッドは static メソッドなので、<code>Thread.interrupted()</code> を使用するほうが単純明解です。
</p>

    
<h3><a name="STI_INTERRUPTED_ON_UNKNOWNTHREAD">STI: スレッドインスタンスで static Thread.interrupted() を呼び出している (STI_INTERRUPTED_ON_UNKNOWNTHREAD)</a></h3>


<p>
このメソッドは、カレントスレッドでない Thread オブジェクトであるように見える Thread オブジェクトで <code>Thread.interrupted()</code> を呼び出しています。
<code>interrupted</code> メソッドは static なので、作成者が意図したこととは異なるオブジェクトで呼び出されます。
</p>

    
<h3><a name="SE_METHOD_MUST_BE_PRIVATE">Se: 直列化機構のために private にしなければならないメソッド (SE_METHOD_MUST_BE_PRIVATE)</a></h3>


<p>
このクラスは、<code>Serializable</code> インタフェースを実装して、カスタム直列化/直列化復元のためのメソッドを定義しています。
しかし、そのメソッドが private として宣言されていないので、直列化/直列化復元 API によって無視されます。
</p>

    
<h3><a name="SE_READ_RESOLVE_IS_STATIC">Se: readResolve メソッドが static メソッドとして宣言されている (SE_READ_RESOLVE_IS_STATIC)</a></h3>


<p>
<code>readResolve</code> メソッドが直列化機構で認識されるためには static メソッドとして宣言してはいけません。
</p>

    
<h3><a name="TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED">TQ: 型修飾子でアノテーションされた値がその修飾子を付けてはならない値を必要とする場所で使われている (TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED)</a></h3>


<p>
型修飾子であのてーとされた値がその修飾子を付けてはならない値を必要とする場所で使われています。
</p>
<p>
より正確に、when=ALWAYS を指定した型修飾子でアノテートされた値が到達することが保証されているか同じ型修飾子で when=NEVER を指定する場所で使用しています。
</p>
<p>
たとえば、@NonNegative が型修飾子アノテーション @Negative(when=When.NEVER) の略称だとします。
以下のコードは、return 文が ＠NonNegative 値を要求するが ＠Negative としてマークされている値を受け取るのでこの警告を生成します。
</p>
<blockquote><pre>
public @NonNegative Integer example(@Negative Integer value) {
    return value;
}
</pre></blockquote>

    
<h3><a name="TQ_COMPARING_VALUES_WITH_INCOMPATIBLE_TYPE_QUALIFIERS">TQ: 互換性のない型修飾子による比較値 (TQ_COMPARING_VALUES_WITH_INCOMPATIBLE_TYPE_QUALIFIERS)</a></h3>


<p>
型修飾子アノテーションを指定した値がその修飾子のない値と比較しています。
</p>
<p>
より正確に、when=ALWAYS を指定した型修飾子でアノテートされた値が同じ型修飾子で when=NEVER を指定する値と比較しています。
</p>
<p>
たとえば、@NonNegative が型修飾子アノテーション @Negative(when=When.NEVER) の略称だとします。
以下のコードは、return 文が @NonNegative 値を要求するが、@Negative としてマークされている値を受け取るのでこの警告を生成します。
</p>
<blockquote><pre>
public boolean example(@Negative Integer value1, @NonNegative Integer value2) {
    return value1.equals(value2);
}
</pre></blockquote>

    
<h3><a name="TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: 型修飾子を付けていないかもしれない値がその型修飾子を必要とする方法で常に使われている (TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK)</a></h3>


<p>
型修飾子によって示された値のインスタンスではない可能性としてアノテートされた値です。
値は、その型修飾子によって示された値を必要とする方法で使われることが保証されています。
</p>

    
<h3><a name="TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: 型修飾子を付けているかもしれない値がその型修飾子を禁止する方法で常に使われている (TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK)</a></h3>


<p>
型修飾子によって示された値のインスタンスである可能性としてアノテートされた値です。
値は、その型修飾子によって示された値を禁止する方法で使われることが保証されています。
</p>

    
<h3><a name="TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED">TQ: 型修飾子でアノテートされていない値がその修飾子が付けられた値を必要とする場所で使われている (TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED)</a></h3>


<p>
型修飾子でアノテートされていない値がその修飾子が付けられた値を必要とする場所で使われています。
</p>
<p>
より正確に、when=NEVER を指定した型修飾子でアノテートされた値が同じ型修飾子で when=ALWAYS を指定する場所で使用しています。
</p>

    
<h3><a name="TQ_UNKNOWN_VALUE_USED_WHERE_ALWAYS_STRICTLY_REQUIRED">TQ: 型修飾子がない値が修飾子を必要とする場所で使われている (TQ_UNKNOWN_VALUE_USED_WHERE_ALWAYS_STRICTLY_REQUIRED)</a></h3>


<p>
値が型修飾子アノテーションを必要とする方法で使われています。型修飾子は厳密なので、ツールは適切なアノテーションを指定していない値を拒絶します。
</p>
<p>
厳密なアノテーションを指定しているので値を型変換します。戻り値が厳密なアノテーションでアノテートされる同一性機能を定義してください。
これは、厳密な型修飾子アノテーションで非アノテート値を値に変える唯一の方法です。
</p>

    
<h3><a name="UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">UMAC: 呼び出し不可能なメソッドが無名クラスで定義されている (UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS)</a></h3>


<p>
この無名クラスは、直接呼び出されないスーパークラスのメソッドをオーバーライドしていないメソッドを定義しています。
他のクラスのメソッドが無名クラスで宣言されたメソッドを直接呼び出せないので、このメソッドは呼び出し不可能であると思われます。
メソッドは単にデッドコードであるかもしれません。しかし、メソッドがスーパークラスで宣言されるメソッドをオーバーライドすることを意図した可能性もあります。
そして、タイプミスまたは他の誤りのために、メソッドは、実際、それが意図されるメソッドをオーバーライドしません。
</p>

    
<h3><a name="UR_UNINIT_READ">UR: コンストラクタで初期化されていないフィールドを読み出している (UR_UNINIT_READ)</a></h3>


<p>
このコンストラクタは、まだ値が代入されていないフィールドを読み出しています。
多くの場合、プログラマがコンストラクタのパラメータの代わりに誤ってフィールドを使用するときに起きます。
</p>

    
<h3><a name="UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR">UR: スーパークラスのコンストラクタから呼び出されるメソッドで初期化されていないフィールドを読み出している (UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR)</a></h3>


<p>
このメソッドは、スーパークラスのコンストラクタで呼びされています。この時点では、クラスのフィールドはまだ初期化されていません。
</p>
<p>
これはたくさんの具象クラスを作るためです。以下のクラスを検討してください。
</p>
<blockquote><pre>
abstract class A {
    int hashCode;
    abstract Object getValue();
    
    A() {
        hashCode = getValue().hashCode();
    }
}

class B extends A {
    Object value;

    B(Object v) {
        this.value = v;
    }

    Object getValue() {
        return value;
    }
}
</pre></blockquote>
<p>
<code>B</code> が構築されるとき、<code>B</code> のコンストラクタが <code>value</code> に値を設定する前に、<code>A</code> クラスのコンストラクタが呼び出されます。
したがって、<code>A</code> のコンストラクタが <code>getValue</code> を呼び出すとき、<code>value</code> の初期化されていない値が読み出されます。
</p>


    
<h3><a name="DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY">USELESS_STRING: 名前のない配列で toString メソッドを呼び出している (DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY)</a></h3>


<p>
このコードは、無名の配列で <code>toString</code> メソッドを呼び出しています。「[C@16f0472」のようなかなり役に立たない結果を生成します。
配列のコンテンツを与え、読める文字列に変換するために、<code>Arrays.toString()</code> を使うことを検討してください。<br>
『Programming Puzzlers』の第3章、パズル12を参照してください。
</p>

    
<h3><a name="DMI_INVOKING_TOSTRING_ON_ARRAY">USELESS_STRING: 配列で toString メソッドを呼び出している (DMI_INVOKING_TOSTRING_ON_ARRAY)</a></h3>


<p>
このコードは、配列で <code>toString</code> メソッドを呼び出しています。「[C@16f0472」のようなかなり役に立たない結果を生成します。
配列のコンテンツを与え、読める文字列に変換するために、<code>Arrays.toString()</code> を使うことを検討してください。<br>
『Programming Puzzlers』の第3章、パズル12を参照してください。
</p>

    
<h3><a name="VA_FORMAT_STRING_BAD_CONVERSION_FROM_ARRAY">USELESS_STRING: 書式文字列を使用して役に立たない方法で配列をフォーマットしている (VA_FORMAT_STRING_BAD_CONVERSION_FROM_ARRAY)</a></h3>


<p>
書式文字列でフォーマットされている引数の1つは配列です。
これは [I@304282 のようなかなり役に立たない書式を使用してフォーマットされます。それは配列のコンテンツを表示しません。
フォーマットで扱う前に <code>Arrays.asList(...)</code> を使用して配列をラップすることを検討してください。
</p>

    
<h3><a name="UWF_NULL_FIELD">UwF: null に設定されるだけのフィールド (UWF_NULL_FIELD)</a></h3>


<p>
このフィールドに定数値 null を書き込みます。したがって、フィールドの読み出しは null を返します。
誤りをチェックしてください。使わないなら除去してください。
</p>

    
<h3><a name="UWF_UNWRITTEN_FIELD">UwF: 書き込まれていないフィールド (UWF_UNWRITTEN_FIELD)</a></h3>


<p>
このフィールドは決して書き込まれません。このフィールドからの読み出しはデフォルト値を返します。
誤りをチェックしてください (フィールドは初期化するべきでしたか？)。使わないなら除去してください。
</p>

    
<h3><a name="VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG">VA: 可変長引数を期待しているメソッドにプリミティブ型の配列を渡している (VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG)</a></h3>


<p>
このコードは可変長引数をとるメソッドにプリミティブ型の配列を渡しています。
これは、プリミティブ型の配列を保持するために長さが1の配列を作成してメソッドに渡します。
</p>

    
<h3><a name="LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE">LG: ロガーの変更は OpenJDK の弱参照が原因で潜在的に失われる (LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE)</a></h3>


<p>
OpenJDK は、潜在的非互換性を取り入れました。特に、<code>java.util.logging.Logger</code> は振る舞いが変更されています。
強参照を使用する代わりに、現在、内部的に弱参照を使用しています。
それは理にかなった変更ですが、残念ながらいくつかのコードは古い振る舞いに依存しています。
ロガーの構成を変更するとき、ロガーへの参照を捨てます。
つまり、ガベージコレクタはそのメモリを回収できます。それは、ロガーの構成が失われることを意味します。<br>
たとえば、以下を検討してください。
</p>
<blockquote><pre>
public static void initLogging() throws Exception {
    Logger logger = Logger.getLogger("edu.umd.cs");
    logger.addHandler(new FileHandler()); // ロガーの構成の変更
    logger.setUseParentHandlers(false); // 別のロガーの構成の変更
}
</pre></blockquote>
<p>
ロガーの参照は、メソッドの終わり (メソッドは脱出しません) で失われるので、
<code>initLogging</code> の呼び出しの後でガベージコレクションの循環があるなら、ロガー構成は失われます (なぜなら Logger は弱参照を保持するだけなので)。
</p>
<blockquote><pre>
public static void main(String[] args) throws Exception {
    initLogging(); // ファイルハンドラーをロガーに追加する
    System.gc(); // ロガーの構成が失われる
    Logger.getLogger("edu.umd.cs").info("Some message"); // 期待したようにファイルに記録されません
}
</pre></blockquote>
<p>
Ulf Ochsenfahrt と Eric Fellheimer
</p>

    
<h3><a name="OBL_UNSATISFIED_OBLIGATION">OBL: ストリームやリソースのクリーンアップに失敗するかもしれないメソッド (OBL_UNSATISFIED_OBLIGATION)</a></h3>


<p>
このメソッドは、ストリーム、データベースオブジェクト、または明示的にクリーンアップ操作を必要としている他のリソースのクリーンアップ (クローズする、片付ける) に失敗するかもしれません。
</p>   
<p>
一般に、メソッドがストリープや他のリソースを開いたなら、メソッドはストリームやリソースがメソッドが戻る前にクリーンアップされることを確認するために、try/finally ブロックを使用するべきです。
</p>
<p>
このバグパターンは、OS_OPEN_STREAM と ODR_OPEN_DATABASE_RESOURCE と基本的に同じですが異なる (そして、うまくいけばより良い) 静的解析技術に基づいています。
私たちは、このバグパターンの有効性についてのフィードバックを得ることに関心があります。
どちらかの方法でフィードバックを送ってください。
</p>
<ul>
  <li>send email to findbugs@cs.umd.edu</li>
  <li>file a bug report: <a href="http://findbugs.sourceforge.net/reportingBugs.html">http://findbugs.sourceforge.net/reportingBugs.html</a></li>
</ul>
<p>
特に、このバグパターンの誤検出抑制探索法は詳細にわたって調整されていないので、誤検出についてのレポートは我々の助けになります。 
</p>
<p>
解析技術の説明は、Weimer と Necula による <i>Finding and Preventing Run-Time Error Handling Mistakes</i> を参照してください。 
</p>

    
<h3><a name="OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE">OBL: チェック例外でストリームやリソースのクリーンアップに失敗するかもしれないメソッド (OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE)</a></h3>


<p>
このメソッドは、ストリーム、データベースオブジェクト、または明示的にクリーンアップ操作を必要としている他のリソースのクリーンアップ (クローズする、片付ける) に失敗するかもしれません。
</p>   
<p>
一般に、メソッドがストリープや他のリソースを開いたなら、メソッドはストリームやリソースがメソッドが戻る前にクリーンアップされることを確認するために、try/finally ブロックを使用するべきです。
</p>
<p>
このバグパターンは、OS_OPEN_STREAM と ODR_OPEN_DATABASE_RESOURCE と基本的に同じですが異なる (そして、うまくいけばより良い) 静的解析技術に基づいています。
私たちは、このバグパターンの有効性についてのフィードバックを得ることに関心があります。
どちらかの方法でフィードバックを送ってください。
</p>
<ul>
  <li>send email to findbugs@cs.umd.edu</li>
  <li>file a bug report: <a href="http://findbugs.sourceforge.net/reportingBugs.html">http://findbugs.sourceforge.net/reportingBugs.html</a></li>
</ul>
<p>
特に、このバグパターンの誤検出抑制探索法は詳細にわたって調整されていないので、誤検出についてのレポートは我々の助けになります。 
</p>
<p>
解析技術の説明は、Weimer と Necula による <i>Finding and Preventing Run-Time Error Handling Mistakes</i> を参照してください。 
</p>

      
<h3><a name="DM_CONVERT_CASE">Dm: 呼び出したメソッドの Locale パラメータの使用を検討する (DM_CONVERT_CASE)</a></h3>


<p>
文字列がプラットホームのデフォルトエンコーディングを使用して大文字、小文字に変換されています。
国際文字で使われると不適切な変換になるかもしれません。
</p>
<ul>
  <li>String.toUpperCase(Locale l)</li>
  <li>String.toLowerCase(Locale l)</li>
</ul>

    
<h3><a name="DM_DEFAULT_ENCODING">Dm: デフォルトエンコーディングへの依存 (DM_DEFAULT_ENCODING)</a></h3>


<p>
byte から String (または String から byte) への変換で、デフォルトプラットホームエンコーディングが適切であると仮定するメソッドの呼び出しを発見しました。
これは、アプリケーションの振る舞いがプラットホーム間で異なる原因となります。代替 API を使用して、明示的に文字セット名または Charset オブジェクトを指定して下さい。
</p>

    
<h3><a name="DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED">DP: doPrivileged ブロック内で作成されるべきクラスローダ (DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED)</a></h3>


<p>
このコードはクラスローダを作成していますが、セキュリティ管理がインストールされるなら許可が必要です。
このコードがセキュリティ許可がないコードによって呼び出されるなら、クラスローダの作成は doPrivileged ブロックの中で行う必要があります。
</p>

    
<h3><a name="DP_DO_INSIDE_DO_PRIVILEGED">DP: doPrivileged ブロック内で呼び出すべきメソッド (DP_DO_INSIDE_DO_PRIVILEGED)</a></h3>


<p>
このコードは、セキュリティ許可チェックが必要なメソッドを呼び出しています。
このコードにセキュリティ許可が与えられるとしても、セキュリティ許可を持たないコードによって呼び出されるなら doPrivileged ブロックの中で呼び出す必要があります。
</p>

    
<h3><a name="EI_EXPOSE_REP">EI: 可変オブジェクトへの参照を返すことによって内部表現を暴露するかもしれないメソッド (EI_EXPOSE_REP)</a></h3>


<p>
オブジェクトのフィールドに格納された可変オブジェクトの参照を返すと、オブジェクトの内部表現を暴露します。
インスタンスが信頼できないコードによってアクセスされるなら、可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトの新しいコピーを返すことは、多くの状況でより良いアプローチです。
</p>

    
<h3><a name="EI_EXPOSE_REP2">EI2: 可変オブジェクトへの参照を取り込むことによって内部表現を暴露するかもしれないメソッド (EI_EXPOSE_REP2)</a></h3>


<p>
このコードは、オブジェクトの内部表現に外部の可変オブジェクトの参照を格納しています。
インスタンスが信頼できないコードによってアクセスされるなら、可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトの新しいコピーを返すことは、多くの状況でより良いアプローチです。
</p>

    
<h3><a name="FI_PUBLIC_SHOULD_BE_PROTECTED">FI: ファイナライザは public ではなく protected にすべき (FI_PUBLIC_SHOULD_BE_PROTECTED)</a></h3>


<p>
このクラスの <code>finalize</code> メソッドは public ではなく、protected にすべきです。
</p>

    
<h3><a name="EI_EXPOSE_STATIC_REP2">MS: static フィールドに可変オブジェクトを格納することによって、内部の静的状態を暴露するかもしれないメソッド (EI_EXPOSE_STATIC_REP2)</a></h3>


<p>
このコードは、static フィールドに外部の可変オブジェクトを格納しています。
可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトのコピーを保存することは、多くの状況でより良いアプローチです。
</p>

    
<h3><a name="MS_CANNOT_BE_FINAL">MS: final でないフィールドは悪質なコードから保護できない (MS_CANNOT_BE_FINAL)</a></h3>


<p>
この可変 static フィールドは、悪質なコードや偶然別のパッケージによって変更される可能性があります。
残念ながらこのような使い方は簡単に解決できません。
</p>

    
<h3><a name="MS_EXPOSE_REP">MS: 配列を返すことによって内部表現を暴露するかもしれない public static メソッド (MS_EXPOSE_REP)</a></h3>


<p>
public static メソッドは、クラスの 静的な状態の一部である配列の参照を返します。
このメソッドを呼び出すどんなコードも、基底配列を自由に変更できます。
解決策は、配列のコピーを返すことです。
</p>

    
<h3><a name="MS_FINAL_PKGPROTECT">MS: final かつパッケージプロテクテッドにすべきフィールド (MS_FINAL_PKGPROTECT)</a></h3>


<p>
この可変 static フィールドは、悪質なコードや偶然別のパッケージによって変更される可能性があります。
フィールドは、脆弱性を回避するために final および/またはパッケージプロテクテッドにします。
</p>

    
<h3><a name="MS_MUTABLE_ARRAY">MS: 可変配列のフィールド (MS_MUTABLE_ARRAY)</a></h3>


<p>
この final static フィールドは、配列を参照しているので、悪質なコードや偶然別のパッケージによってアクセスされる可能性があります。
このコードは、配列のコンテンツを自由に変更できます。
</p>

    
<h3><a name="MS_MUTABLE_HASHTABLE">MS: 可変 Hashtable のフィールド (MS_MUTABLE_HASHTABLE)</a></h3>


<p>
この final static フィールドは、Hashtable を参照しているので、悪質なコードや偶然別のパッケージによってアクセスされる可能性があります。
このコードは、Hashtable のコンテンツを自由に変更できます。
</p>

    
<h3><a name="MS_OOI_PKGPROTECT">MS: インタフェースから移動してパッケージプロテクテッドにすべきフィールド (MS_OOI_PKGPROTECT)</a></h3>


<p>
インタフェースに定義された final static フィールドが、配列や Hashtable などの可変オブジェクトを参照しています。
この可変オブジェクトは、悪質なコードや偶然別のパッケージによって変更される可能性があります。
これを解決するために、フィールドはクラスへ移動する必要があり、脆弱性を回避するためにパッケージプロテクテッドにします。
</p>

    
<h3><a name="MS_PKGPROTECT">MS: パッケージプロテクテッドにすべきフィールド (MS_PKGPROTECT)</a></h3>


<p>
この可変 static フィールドは、悪質なコードや偶然別のパッケージによって変更される可能性があります。
フィールドは、脆弱性を回避するためにパッケージプロテクテッドにします。
</p>

    
<h3><a name="MS_SHOULD_BE_FINAL">MS: final にすべきフィールド (MS_SHOULD_BE_FINAL)</a></h3>


<p>
final でない public static フィールドは、悪質なコードや偶然別のパッケージによって変更される可能性があります。
フィールドは、脆弱性を回避するために final にします。
</p>

    
<h3><a name="MS_SHOULD_BE_REFACTORED_TO_BE_FINAL">MS: final でないフィールドはリファクタリングするべき (MS_SHOULD_BE_REFACTORED_TO_BE_FINAL)</a></h3>


<p>
final でない public static フィールドは、悪質なコードや偶然別のパッケージによって変更される可能性があります。
フィールドは、脆弱性を回避するために final にします。
しかしながら、スタティックイニシャライザには複数のフィールドへの書き込みがあるので、何らかのリファクタリングを必要とするでしょう。
</p>

    
<h3><a name="AT_OPERATION_SEQUENCE_ON_CONCURRENT_ABSTRACTION">AT: 並行抽象の呼び出しシーケンスはアトミックではないかもしれない (AT_OPERATION_SEQUENCE_ON_CONCURRENT_ABSTRACTION)</a></h3>


<p>
このコードには並行抽象化 （たとえば、並行ハッシュマップ） の呼び出しシーケンスがあります。
これらの呼び出しは原子的に実行されません。
</p>

    
<h3><a name="DC_DOUBLECHECK">DC: フィールドのダブルチェックの可能性 (DC_DOUBLECHECK)</a></h3>


<p>
このメソッドにはダブルチェックロッキングのインスタンスがあるかもしれません。このイディオムは、Java のメモリモデルでは正しくありません。<br>
詳細は、<a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html" >http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html</a> を参照してください。
</p>

    
<h3><a name="DL_SYNCHRONIZATION_ON_BOOLEAN">DL: Boolean の同期化 (DL_SYNCHRONIZATION_ON_BOOLEAN)</a></h3>


<p>
<code>Boolean</code> のようなボクシングされたプリミティブ型の定数で同期化しています。
</p>
<blockquote><pre>
private static Boolean inited = Boolean.FALSE;

synchronized(inited) { 
    if (!inited) {
        init();
        inited = Boolean.TRUE;
    }
}
</pre></blockquote>
<p>
一般には2つの <code>Boolean</code> オブジェクトだけが存在しています。
このコードは他の無関係なコードと同じオブジェクトで同期化している可能性があるので、無応答やデッドロックの原因になります。
</p>

    
<h3><a name="DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE">DL: デッドロックの原因になる可能性があるボクシングされたプリミティブ型の同期化 (DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE)</a></h3>


<p>
このコードは、Integer のようなボクシングされたプリミティブ型の定数で同期化しています。
</p>
<blockquote><pre>
private static Integer count = 0;

synchronized(count) { 
    count++;
}
</pre></blockquote>
<p>
<code>Integer</code> オブジェクトはキャッシュして共有される可能性があります。
他の無関係なコードと同じオブジェクトで同期化している可能性があるので、無応答やデッドロックの原因になります。
</p>
<p>
CERT の <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> を参照してください。
</p>

    
<h3><a name="DL_SYNCHRONIZATION_ON_SHARED_CONSTANT">DL: 正準化した文字列の同期化 (DL_SYNCHRONIZATION_ON_SHARED_CONSTANT)</a></h3>


<p>
このコードは、正準化した文字列で同期化しています。
</p>
<blockquote><pre>
private static String LOCK = "LOCK";

synchronized(LOCK) {
    ...
}
</pre></blockquote>
<p>
文字列定数は正準化され、Java 仮想マシンによってロードされたすべてのクラス全体で共有されます。
したがって、これは他のコードがロックしているかもしれない何かをロックしている可能性があります。
これはブロッキングとデッドロックの振る舞いの診断を難しくして、とても奇妙な結果になる可能性があります。 <br>
詳細は、<a href="http://www.javalobby.org/java/forums/t96352.html">http://www.javalobby.org/java/forums/t96352.html</a> と <a href="http://jira.codehaus.org/browse/JETTY-352">http://jira.codehaus.org/browse/JETTY-352</a> を参照してください。
</p>

    
<h3><a name="DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE">DL: ボクシングされたプリミティブ値の同期化 (DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE)</a></h3>


<p>
このコードは、明らかに共有されていない <code>Integer</code> のようなボクシングされたプリミティブ型で同期化しています。
</p>
<blockquote><pre>
private static final Integer fileLock = new Integer(1);

synchronized(fileLock) { 
    .. do something ..
}
</pre></blockquote>
<p>
このコードは、 fileLock を以下のように宣言するとより良くなります。
</p>
<blockquote><pre>
private static final Object fileLock = new Object();
</pre></blockquote>
<p>
既存のコードとしては間違っていないのかもしれませんが、紛らわしいので将来リファクタリングするべきかもしれません。
たとえば、IntelliJ の "Remove Boxing" のようなリファクタリングは Java 仮想マシンを通して共有される正準化された <code>Integer</code> オブジェクトを使用するように置き換えてしまい、非常に紛らわしい振る舞いと潜在的デッドロックの原因になります。
</p>

    
<h3><a name="DM_MONITOR_WAIT_ON_CONDITION">Dm: Condition で wait メソッドを呼び出している (DM_MONITOR_WAIT_ON_CONDITION)</a></h3>


<p>
このメソッドは、<code>java.util.concurrent.locks.Condition</code> オブジェクトで <code>wait</code> メソッドを呼び出しています。
<code>Condition</code> オブジェクトを待機させるためには <code>Condition</code> インタフェースで定義された <code>await</code> メソッドを使用するべきです。
</p>

    
<h3><a name="DM_USELESS_THREAD">Dm: デフォルトの空の run メソッドを使用して作成されたスレッド (DM_USELESS_THREAD)</a></h3>


<p>
このメソッドは、<code>Thread</code> クラスから派生した <code>run</code> メソッドを指定していないか、<code>Runnable</code> オブジェクトを渡すことなく、スレッドを作成しています。
このスレッドは、時間の無駄です。
</p>

    
<h3><a name="ESync_EMPTY_SYNC">ESync: 空の synchronized ブロック (ESync_EMPTY_SYNC)</a></h3>


<p>
このコードには空の synchronized ブロックがあります。
</p>
<blockquote><pre>
synchronized() {
}
</pre></blockquote>
<p>
空の synchronized ブロックは巧妙で正しく使用するのは困難です。
空の synchronized ブロックはわざとらしくて決して良い解決策ではありません。
</p>

    
<h3><a name="IS2_INCONSISTENT_SYNC">IS: 一貫性のない同期化 (IS2_INCONSISTENT_SYNC)</a></h3>


<p>
このクラスのフィールドは、同期化に関して一貫性なくアクセスされるように見えます。
このバグレポートは、バグパターンディテクタが以下のように判断したことを示します。
</p>
<ul>
  <li>クラスは、ロックされたアクセスとアンロックされたアクセスが混在していて</li>
  <li>クラスは、javax.annotation.concurrent.NotThreadSafe としてアノテートされません</li>
  <li>少なくとも1つのロックされたアクセスがクラス自身のメソッドの1つによって実行され、</li>
  <li>読み出しの2倍の重み付けをした書き込みで、非同期フィールドのアクセス (読み出しと書き込み) 数がすべてのアクセスのわずか1/3</li>
</ul>
<p
このバグパターンに合致する典型的なバグは、スレッドセーフを意図したクラスでメソッドを同期化させることを忘れていることです。
</p>
<p>
ディテクタがどこでフィールドが同期化なしでアクセスされると信じていたかを示すコードの場所に「非同期アクセス」というラベルがついているノードを選択できます。
</p>
<p>
不正確ないろいろな原因がこのディテクタにあることに注意してください。
たとえば、ディテクタはロックを保持されるすべての状況を静的に検出できるというわけではありません。
また、ディテクタがロックされたアクセスとアンロックされたアクセスの区別が正確なときでも、問題のコードは依然として正しいかもしれません。
</p>

    
<h3><a name="IS_FIELD_NOT_GUARDED">IS: 並行アクセスに対してガードされていないフィールド (IS_FIELD_NOT_GUARDED)</a></h3>


<p>
このフィールドは、net.jcip.annotations.GuardedBy または javax.annotation.concurrent.GuardedBy でアノテートされていますが、アノテーションに違反すると思われる方法でアクセスできます。
</p>

    
<h3><a name="JLM_JSR166_LOCK_MONITORENTER">JLM: Lock で同期化している (JLM_JSR166_LOCK_MONITORENTER)</a></h3>


<p>
このメソッドは、<code>java.util.concurrent.locks.Lock</code> を実装したオブジェクトで同期化しています。
そのようなオブジェクトは <code>synchronized (...)</code> 構文よりも <code>acquire()</code>/<code>release()</code> を使用してロックとロックの解除をします。
</p>

    
<h3><a name="JLM_JSR166_UTILCONCURRENT_MONITORENTER">JLM: java.util.concurrent のインスタンスで同期化している (JLM_JSR166_UTILCONCURRENT_MONITORENTER)</a></h3>


<p>
このメソッドは、java.util.concurrent パッケージのクラス (またはサブクラス) のインスタンスで同期化しています。
これらのクラスのインスタンスは、<code>synchronized</code> の使用とは違う互換性のないそれら自身の並行制御メカニズムを持っています。
たとえば、<code>AtomicBoolean</code> で同期しても、他のスレッドが <code>AtomicBoolean</code> を変更するのを防ぎません。
</p>
<p>
そのようなコードは正しいかもしれないが、将来コードを維持しなければならない人々を混乱させるかもしれないので慎重にレビューし文書化するべきです、
</p>

    
<h3><a name="JML_JSR166_CALLING_WAIT_RATHER_THAN_AWAIT">JLM: util.concurrent 抽象でモニタスタイルの wait メソッドを使用している (JML_JSR166_CALLING_WAIT_RATHER_THAN_AWAIT)</a></h3>


<p>
このメソッドは、<code>await()</code> メソッド、<code>signal</code> メソッド、<code>signalAll</code> メソッドを提供するオブジェクト
(たとえば、util.concurrent の Condition オブジェクト) で、<code>wait</code> メソッド、<code>notify</code> メソッド、<code>notifyAll</code> メソッドを呼び出しています。
これはおそらくあなたが望むことではありません。たとえそれを望むとしても、他の開発者が非常に紛らわしいことを理解して、設計を変更することを検討するべきです。
</p>


<h3><a name="LI_LAZY_INIT_STATIC">LI: static フィールドの間違った遅延初期化 (LI_LAZY_INIT_STATIC)</a></h3>


<p>
このメソッドにはvolatile でない static フィールドの非同期な遅延初期化があります。
コンパイラやプロセッサが命令を並べ替えるかもしれないので、メソッドが複数のスレッドによって呼び出されるかもしれないなら、
スレッドは完全に初期化されたオブジェクトを見るとは保証されていません。
フィールドにアクセスした際に、中途半端に初期化されたインスタンスが見えてしまう危険があります。
この問題を修正するために、フィールドを volatile にできます。<br>
詳細は、<a href="http://www.cs.umd.edu/~pugh/java/memoryModel/">Java Memory Model web site</a> を参照してください。
</p>

    
<h3><a name="LI_LAZY_INIT_UPDATE_STATIC">LI: 更新される static フィールドの間違った遅延初期化 (LI_LAZY_INIT_UPDATE_STATIC)</a></h3>


<p>
このメソッドにはstatic フィールドの非同期な遅延初期化があります。
フィールドが設定された後で、その場所に格納されるオブジェクトはさらに更新されるかアクセスされます。
それが設定されるとすぐに、フィールドの設定は他のスレッドに見えます。
フィールドを設定するさらなるアクセスがオブジェクトを初期化するのに役に立つなら、
それが完全に初期化されるまでどんな他のスレッドも格納されたオブジェクトにアクセスするのを防がないかぎり、非常に深刻なマルチスレッドバグがあります。
</p>
<p>
たとえメソッドが複数のスレッドによって決して呼び出されないと確信していても、
それは、フィールドに設定している値が完全にデータを読み込まれるか初期化されるまで、 static フィールドを設定しないほうが良いかもしれません。
</p>

    
<h3><a name="ML_SYNC_ON_FIELD_TO_GUARD_CHANGING_THAT_FIELD">ML: フィールドを同期化でガードしようとする無駄な試み (ML_SYNC_ON_FIELD_TO_GUARD_CHANGING_THAT_FIELD)</a></h3>


<p>
このメソッドは、フィールドの同時更新に対して同期化でガードしようとしています。しかし、フィールドをガードするとフィールドではなく、フィールドが参照するオブジェクトのロックを獲得します。
これはあなたが必要とする相互排除を提供しないかもしれません。
他のスレッドは (他の目的のための) 参照されたオブジェクトのロックを獲得するかもしれません。<br>
このパターンの例は以下のようになります。
</p>
<blockquote><pre>
private Long myNtfSeqNbrCounter = new Long(0);
private Long getNotificationSequenceNumber() {
     Long result = null;
     synchronized(myNtfSeqNbrCounter) {
         result = new Long(myNtfSeqNbrCounter.longValue() + 1);
         myNtfSeqNbrCounter = new Long(result.longValue());
     }
     return result;
}
</pre></blockquote>

    
<h3><a name="ML_SYNC_ON_UPDATED_FIELD">ML: 更新されるフィールドで同期化しているメソッド (ML_SYNC_ON_UPDATED_FIELD)</a></h3>


<p>
このメソッドは、可変フィールドから参照されたオブジェクトで同期化しています。
異なるスレッドが異なるオブジェクトで同期化しているかもしれないので、これは有効な意味を持っている可能性が低いです。
</p>

    
<h3><a name="MSF_MUTABLE_SERVLET_FIELD">MSF: 可変サーブレットフィールド (MSF_MUTABLE_SERVLET_FIELD)</a></h3>


<p>
Web サーバは、一般的にサーブレットや JSP クラスのインスタンスを1つだけ作成します (すなわち、シングルトンとして扱います)。
複数のスレッドが複数同時に発生するリクエストを処理するためにインスタンスのメソッドを呼び出します。
したがって、可変インスタンスフィールドは一般に競合状態を作成します。
</p>

    
<h3><a name="MWN_MISMATCHED_NOTIFY">MWN: 不整合な notify メソッド (MWN_MISMATCHED_NOTIFY)</a></h3>


<p>
このメソッドは、オブジェクトで明らかにロックを保持することなく <code>Object.notify()</code> や <code>Object.notifyAll()</code> を呼び出しています。
保持されるロックがない状態で、<code>notify</code> メソッドや <code>notifyAll</code> メソッドを呼び出すことは、<code>IllegalMonitorStateException</code> をスローすることになります。
</p>

    
<h3><a name="MWN_MISMATCHED_WAIT">MWN: 不整合な wait メソッド (MWN_MISMATCHED_WAIT)</a></h3>


<p>
このメソッドは、オブジェクトで明らかにロックを保持することなく、<code>Object.wait()</code> を呼び出しています。
保持されるロックがない状態で、<code>wait</code> メソッドを呼び出すことは、<code>IllegalMonitorStateException</code> をスローすることになります。
</p>

    
<h3><a name="NN_NAKED_NOTIFY">NN: 裸の notify メソッド (NN_NAKED_NOTIFY)</a></h3>


<p>
<code>notify</code> メソッドまたは <code>notifyAll</code> メソッドへの呼び出しは可変オブジェクト状態にどんな (明らかな) 付随的な変更ももたらされませんでした。
一般に、別のスレッドが期待しているいくつかの条件が真になったので、モニタで <code>notify</code> メソッドが呼び出されます。
しかしながら、意味がある条件のために、両方のスレッドに見えるヒープオブジェクトを含まなければなりません。
</p>
<p>
可変オブジェクトの状態変更が通知があるメソッドを呼び出したメソッドで起こったかもしれないので、このバグが必ずしもエラーを示すというわけではありません。
</p>

    
<h3><a name="NP_SYNC_AND_NULL_CHECK_FIELD">NP: 同じフィールドでの同期化と null チェック (NP_SYNC_AND_NULL_CHECK_FIELD)</a></h3>


<p>
フィールドは同期化しているので、おそらく null ではないと思われます。
null のフィールドを同期化すると NullPointerException がスローされるので、null チェックは無意味になります。
別のフィールドで同期化したほうがよいです。
</p>

    
<h3><a name="NO_NOTIFY_NOT_NOTIFYALL">No: notifyAll メソッドではなく notify メソッドを使用している (NO_NOTIFY_NOT_NOTIFYALL)</a></h3>


<p>
このメソッドは、<code>notifyAll</code> メソッドではなく <code>notify</code> メソッドを呼び出しています。
モニタが複数の条件のために多くの場合使われます。
<code>notify</code> メソッドの呼び出しは1つのスレッドを起こすだけで起こされたスレッドは呼び出し元が満たした待機条件の1つではないかもしれないことを意味しています。
</p>

    
<h3><a name="RS_READOBJECT_SYNC">RS: readObject メソッドを同期化しているクラス (RS_READOBJECT_SYNC)</a></h3>


<p>
この直列化可能クラスは同期化する <code>readObject</code> メソッド を定義していますが、
直列化復元によって作成されるオブジェクトは1つのスレッドによってだけ到達可能です。
したがって、<code>readObject</code> メソッドは同期化する必要がありません。
<code>readObject</code> メソッドそのものが別のスレッドに見えるようになるオブジェクトの原因になっているなら非常に疑わしいコーディングスタイルの例です。
</p>

    
<h3><a name="RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED">RV: putIfAbsent の戻り値は無視されて putIfAbsent に渡した値は再利用された (RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED)</a></h3>


<p>
<code>putIfAbsent</code> メソッドは、一般に1つの値が与えられたキー (非存在が成功するかどうかの第一の値) と関連することを確認するために使われます。
戻り値を無視して中で渡される値への参照を保持するなら、マップのキーと関連する1つではない値を保持する危険性を冒します。
どれを使用するかが重要であり、マップに格納できないものを使用すると、プログラムは誤った振る舞いをします。
</p>

    
<h3><a name="RU_INVOKE_RUN">Ru: スレッドで run メソッドを呼び出している (RU_INVOKE_RUN)</a></h3>


<p>
このメソッドは、スレッドで 明示的に <code>run</code> メソッドを呼び出しています。
一般に、クラスは新しいスレッドで自己の <code>run</code> メソッドを呼び出してもらうために <code>Runnable</code> インタフェースを実装します。
その場合は、<code>Thread.start()</code> を呼び出すのが正しいです。
</p>

    
<h3><a name="SC_START_IN_CTOR">SC: Thread.start() を呼び出しているコンストラクタ (SC_START_IN_CTOR)</a></h3>


<p>
コンストラクタがスレッドを開始しています。クラスが拡張され、サブクラスが作られるなら間違っていそうです。
なぜなら、サブクラスのコンストラクタでスレッドが開始される前に、スーパークラスのスレッドが開始してしまうためです。
</p>

    
<h3><a name="SP_SPIN_ON_FIELD">SP: スピンロックをしているメソッド (SP_SPIN_ON_FIELD)</a></h3>


<p>
このメソッドは、フィールドを読み出すループで回り続けます。
コンパイラがフィールドの読み出しをループの外に出すかもしれません。コードを無限ループに変えます。
正しい同期化 (wait/notify を呼び出すように含む) を使うようにクラスを変更するべきです。
</p>

    
<h3><a name="STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">STCAL: static Calendar の呼び出し (STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE)</a></h3>


<p>
たとえ JavaDoc にそれに関する手がかりがないとしても、Calendar はマルチスレッドでの使用は本質的に安全ではありません。
ディテクタは、static フィールドから得られた Calendar のインスタンスの呼び出しを発見しました。
これは疑わしく見えます。
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a> を参照してください。
</p>

    
<h3><a name="STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">STCAL: static DateFormat の呼び出し (STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE)</a></h3>


<p>
JavaDoc に書かれているように、DateFormat はマルチスレッドでの使用は本質的に安全ではありません。
ディテクタは、static フィールドから得られた DateFormat のインスタンスの呼び出しを発見しました。
これは疑わしく見えます。
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a> を参照してください。
</p>

    
<h3><a name="STCAL_STATIC_CALENDAR_INSTANCE">STCAL: static Calendar フィールド (STCAL_STATIC_CALENDAR_INSTANCE)</a></h3>


<p>
たとえ JavaDoc にそれに関する手がかりがないとしても、Calendar はマルチスレッドでの使用は本質的に安全でありません。
正しい同期化をしないでスレッド境界の向こうで1つのインスタンスを共有することは、アプリケーションの誤動作になります。
JDK 5.0に比べて JDK 1.4 のほうが問題が表面化するように思われ、おそらく sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate() の ArrayIndexOutOfBoundsExceptions や IndexOutOfBoundsExceptions がランダムに発生します。
直列化問題も経験するかもしれません。インスタンスフィールドを使うことを推奨します。<br>
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a> を参照してください。
</p>

    
<h3><a name="STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE">STCAL: static DateFormat (STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE)</a></h3>


<p>
JavaDoc に書かれているように、DateFormat はマルチスレッドでの使用は本質的に安全ではありません。
正しい同期化をしないでスレッド境界の向こうで1つのインスタンスを共有することは、アプリケーションの誤動作になります。
JDK 5.0に比べて JDK 1.4 のほうが問題が表面化するように思われ、おそらく sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate() の ArrayIndexOutOfBoundsExceptions や IndexOutOfBoundsExceptions がランダムに発生します。
直列化問題も経験するかもしれません。インスタンスフィールドを使うことを推奨します。<br>
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a> を参照してください。
</p>

    
<h3><a name="SWL_SLEEP_WITH_LOCK_HELD">SWL: ロックを保持して Thread.sleep() を呼び出しているメソッド (SWL_SLEEP_WITH_LOCK_HELD)</a></h3>


<p>
このメソッドは、ロックを保持して、<code>Thread.sleep()</code> を呼び出しています。
他のスレッドがロックを獲得するために待機しているかもしれないので、ひどい性能とスケーラビリティ、またはデッドロックになるかもしれません。
ロックで <code>wait</code> メソッドを呼び出すことはかなり良い考えで、ロックを解除して他のスレッドが実行するのを許可します。
</p>

    
<h3><a name="TLW_TWO_LOCK_WAIT">TLW: 2つ以上のロックを保持して wait メソッドを呼び出している (TLW_TWO_LOCK_WAIT)</a></h3>


<p>
2つ以上のロックを保持して、モニタで待機させるとデッドロックの原因になる場合があります。
<code>wait</code> メソッドを呼び出すと、待機しているオブジェクトのロックを解除するだけで、その他のロックは解除しません。
これは必ずしもバグではありませんが厳密に調べる価値があります。
</p>

    
<h3><a name="UG_SYNC_SET_UNSYNC_GET">UG: 同期化していない get メソッド、同期化している set メソッド (UG_SYNC_SET_UNSYNC_GET)</a></h3>


<p>
このクラスには類似した名前の get メソッドと set メソッドがあり、set メソッドは同期化していて、get メソッドは同期化していません。
get メソッドの呼び出し元がオブジェクトの一貫した状態を必ずしも見るというわけではないので、実行時に間違った振る舞いになるかもしれません。
get メソッドは同期化するべきです。
</p>

    
<h3><a name="UL_UNRELEASED_LOCK">UL: すべての経路でロックが解除されないメソッド (UL_UNRELEASED_LOCK)</a></h3>


<p>
このメソッドは、JSR-166(<code>java.util.concurrent</code>) のロックを獲得していますが、メソッドからのすべての経路で解除していません。
一般に、JSR-166のロックを使用するための正しいイディオムは以下のようになります。
</p>
<blockquote><pre>
Lock l = ...;
l.lock();
try {
    // do something
} finally {
    l.unlock();
}
</pre></blockquote>

    
<h3><a name="UL_UNRELEASED_LOCK_EXCEPTION_PATH">UL: すべての例外経路でロックが解除されないメソッド (UL_UNRELEASED_LOCK_EXCEPTION_PATH)</a></h3>


<p>
このメソッドは、JSR-166(<code>java.util.concurrent</code>) のロックを獲得していますが、メソッドからのすべての例外経路で解除していません。
一般に、JSR-166のロックを使用するための正しいイディオムは以下のようになります。
</p>
<blockquote><pre>
Lock l = ...;
l.lock();
try {
    // do something
} finally {
    l.unlock();
}
</pre></blockquote>

    
<h3><a name="UW_UNCOND_WAIT">UW: wait メソッドの無条件呼び出し (UW_UNCOND_WAIT)</a></h3>


<p>
このメソッドには条件制御フローによってガードされない <code>java.lang.Object.wait()</code> の呼び出しがあります。
このコードは、<code>wait</code> メソッドを呼び出す前に待機するつもりだった条件がすでに満たされていないことを確かめるべきです。
どんな前の通知も無視されます。
</p>

    
<h3><a name="VO_VOLATILE_INCREMENT">VO: volatile フィールドへのインクリメントはアトミックではない (VO_VOLATILE_INCREMENT)</a></h3>


<p>
このコードは、volatile フィールドをインクリメントしています。
volatile フィールドのインクリメントはアトミックではありません。
複数のスレッドが同時にフィールドをインクリメントすると、インクリメントが失われる可能性があります。 
</p>

    
<h3><a name="VO_VOLATILE_REFERENCE_TO_ARRAY">VO: 配列への volatile 参照は、配列要素を volatile として扱わない (VO_VOLATILE_REFERENCE_TO_ARRAY)</a></h3>


<p>
配列に volatile 参照を宣言していますが、あなたが望むものではないかもしれません。
配列への volatile 参照は、配列への参照の読み出し、書き込みは volatile として扱われますが、配列要素は volatile として扱われません。
配列要素を volatile として扱いたいのであれば、J2SE 5.0で提供された java.util.concurrent パッケージのアトミック配列クラスを使用する必要があります。
</p>

    
<h3><a name="WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL">WL: クラスリテラルではなく getClass で同期化している (WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL)</a></h3>


<p>
このインスタンスメソッドは、<code>this.getClass()</code> で同期化しています。
このクラスがサブクラス化されるなら、サブクラスはおそらく意図したことではないサブクラスのためにクラスオブジェクトで同期化します。
たとえば、<code>java.awt.Label</code> の以下のコードを検討してください。
</p>
<blockquote><pre>
private static final String base = "label";
private static int nameCounter = 0;

String constructComponentName() {
    synchronized (getClass()) {
        return base + nameCounter++;
    }
}
</pre></blockquote>
<p>
<code>Label</code> のサブクラスは同じサブクラスで同期化しません。データレースを生じさせます。
代わりに、このコードは、<code>Label.class</code> で同期化するべきです。
</p>
<blockquote><pre>
private static final String base = "label";
private static int nameCounter = 0;

String constructComponentName() {
    synchronized (Label.class) {
        return base + nameCounter++;
    }
}
</pre></blockquote>
<p>
Jason Mehrens によって寄贈されたバグパターン
</p>

    
<h3><a name="WS_WRITEOBJECT_SYNC">WS: writeObject メソッドは同期化しているがその他のメソッドは同期化していないクラス (WS_WRITEOBJECT_SYNC)</a></h3>


<p>
このクラスには同期化している <code>writeObject</code> メソッドがあります。
しかしながら、クラスのその他のメソッドは同期化していません。
</p>

    
<h3><a name="WA_AWAIT_NOT_IN_LOOP">Wa: Condition.await() がループの中にない (WA_AWAIT_NOT_IN_LOOP)</a></h3>


<p>
このメソッドは、ループの中にない <code>java.util.concurrent.await()</code> (またはそのバリエーション) を呼び出しています。
オブジェクトが複数の条件のために使われるなら、呼び出し元が待機するつもりだった条件は実際には発生しないかもしれません。
</p>

    
<h3><a name="WA_NOT_IN_LOOP">Wa: wait メソッドがループの中にない (WA_NOT_IN_LOOP)</a></h3>


<p>
このメソッドは、ループの中にない <code>java.lang.Object.wait()</code> を呼び出しています。
モニタが複数の条件のために使われるなら、呼び出し元が待機するつもりだった条件は実際には発生しないかもしれません。
</p>

    
<h3><a name="BX_BOXING_IMMEDIATELY_UNBOXED">Bx: プリミティブ値がボクシングされて、すぐにアンボクシングされる (BX_BOXING_IMMEDIATELY_UNBOXED)</a></h3>


<p>
プリミティブ値がボクシングされて、すぐにアンボクシングされます。
おそらくアンボクシングされた値が必要な場所で、手動でボクシングをしているためです。
その結果、コンパイラにボクシングの機能を取り消すことを強制しています。
</p>

    
<h3><a name="BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION">Bx: プリミティブ値がプリミティブ型の型変換をするためにボクシングされて、アンボクシングされる (BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION)</a></h3>


<p>
プリミティブ値がコンストラクタでボクシングされて、すぐに異なるプリミティブ型に変換されます (たとえば <code>new Double(d).intValue()</code>)。
直接プリミティブ型の型変換を実行してください (たとえば <code>(int) d</code>)。
</p>

    
<h3><a name="BX_UNBOXING_IMMEDIATELY_REBOXED">Bx: ボクシングされた値がアンボクシングされて、すぐに再ボクシングされる (BX_UNBOXING_IMMEDIATELY_REBOXED)</a></h3>


<p>
ボクシングされた値がアンボクシングされて、すぐに再ボクシングされます。
</p>

    
<h3><a name="DM_BOXED_PRIMITIVE_FOR_PARSING">Bx: ボクシング/アンボクシングはプリミティブを解析する (DM_BOXED_PRIMITIVE_FOR_PARSING)</a></h3>


<p>
ボックス化されたプリミティブは、String から生成されていて、アンボックス化されたプリミティブ値を抽出します。
static parseXXX メソッドを呼び出す方が効率的です。
</p>

    
<h3><a name="DM_BOXED_PRIMITIVE_TOSTRING">Bx: toString メソッドを呼び出すためにプリミティブ型のラッパクラスのインスタンスを作成している (DM_BOXED_PRIMITIVE_TOSTRING)</a></h3>


<p>
<code>toString</code> メソッドを呼び出すために、プリミティブ型のラッパクラスのインスタンスを作成しています。
それよりもプリミティブ値を引数にとる static な <code>toString</code> メソッドを使用したほうが効率的です。
</p>
<table>
   <tr><th>置換前</th><th>置換後</th></tr>
   <tr><td>new Integer(1).toString()</td><td>Integer.toString(1)</td></tr>
   <tr><td>new Long(1).toString()</td><td>Long.toString(1)</td></tr>
   <tr><td>new Float(1.0).toString()</td><td>Float.toString(1.0)</td></tr>
   <tr><td>new Double(1.0).toString()</td><td>Double.toString(1.0)</td></tr>
   <tr><td>new Byte(1).toString()</td><td>Byte.toString(1)</td></tr>
   <tr><td>new Short(1).toString()</td><td>Short.toString(1)</td></tr>
   <tr><td>new Boolean(true).toString()</td><td>Boolean.toString(true)</td></tr>
</table>

    
<h3><a name="DM_FP_NUMBER_CTOR">Bx: 効率が悪い浮動小数点 Number コンストラクタを呼び出しているメソッド (DM_FP_NUMBER_CTOR)</a></h3>


<p>
<code>new Double(double)</code> の使用は、常に新しいブジェクトになることが保証されています。
これに対して、<code>Double.valueOf(double)</code> は、コンパイラ、クラスライブラリ、Java 仮想マシンで値がキャッシュされます。
キャッシュに格納された値を使うことはインスタンス生成を回避し、コードはより高速になります。
</p>
<p>
クラスが J2SE 5.0より前の Java 仮想マシンとの互換性が不要なら、オートボクシングか <code>Double</code>、<code>Float</code> の <code>valueOf</code> メソッドを使用してください。
</p>

    
<h3><a name="DM_NUMBER_CTOR">Bx: 効率が悪い Number コンストラクタを呼び出しているメソッド (DM_NUMBER_CTOR)</a></h3>


<p>
<code>new Integer(int)</code> の使用は、常に新しいブジェクトになることが保証されています。
これに対して、<code>Integer.valueOf(int)</code> は、コンパイラ、クラスライブラリ、Java 仮想マシンで値がキャッシュされます。
キャッシュに格納された値を使うことはインスタンスの作成を回避し、コードはより高速になります。
</p>
<p>
-128から127までの値は対応するキャッシュされたインスタンスを持つことが保証されています。
そして、<code>valueOf</code> メソッドの使用は、コンストラクタを使用するより約3.5倍高速です。
定数範囲外の値は、両方のスタイルの性能は同じです。
</p>
<p>
クラスが J2SE 5.0より前の Java 仮想マシンとの互換性が不要なら、<code>Long</code>、<code>Integer</code>、<code>Short</code>、<code>Character</code>、<code>Byte</code> のインスタンスを作成するときは、オートボクシングか <code>valueOf</code> メソッドを使用してください。
</p>

    
<h3><a name="DMI_BLOCKING_METHODS_ON_URL">Dm: URL の equals メソッドと hashCode メソッドはブロックする (DMI_BLOCKING_METHODS_ON_URL)</a></h3>


<p>
URL の <code>equals</code> メソッドと <code>hashCode</code> メソッドは、ドメイン名の解決を行うので、ひどい性能になる可能性があります。<br>
詳細は、<a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> を参照してください。<br>
その代わりに <code>java.net.URI</code> を使うことを検討してください。
</p>

    
<h3><a name="DMI_COLLECTION_OF_URLS">Dm: URL の Map や Set はひどい性能になる可能性がある (DMI_COLLECTION_OF_URLS)</a></h3>


<p>
このメソッドまたはフィールドは、URL の <code>Map</code> か <code>Set</code> を使用しています。
URL の <code>equals</code> と <code>hashCode</code> は、ドメイン名の解決を行うので、ひどい性能になる可能性があります。<br>
詳細は、<a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> を参照してください。<br>
その代わりに <code>java.net.URI</code> を使うことをを検討してください。
</p>

    
<h3><a name="DM_BOOLEAN_CTOR">Dm: 効率が悪い Boolean コンストラクタを呼び出しているメソッド (DM_BOOLEAN_CTOR)</a></h3>


<p>
<code>java.lang.Boolean</code> の新しいインスタンスを作成するとメモリを浪費します。
<code>Boolean</code> オブジェクトは不変で、2つの有効な値 (<code>Boolean.TRUE</code> と <code>Boolean.FALSE</code>) があります。
その代わりに <code>Boolean</code> オブジェクトを作成するために、<code>Boolean.valueOf</code> メソッド (または J2SE 5.0 のオートボクシング) を使用してください。
</p>

    
<h3><a name="DM_GC">Dm: 明示的なガベージコレクション (DM_GC)</a></h3>


<p>
明示的にガベージコレクションを呼び出しています。ベンチマークの特定の用途を除いて非常に疑わしいです。
</p>
<p>
過去に、<code>close</code> メソッドや <code>finalize</code> メソッドでガベージコレクタを明示的に呼び出していた状況は、巨大なパフォーマンスブラックホールの原因となりました。
ガベージコレクションは、高くつく可能性があります。何百、何千ものガベージコレクションを強制する状況は、システムの停滞をもたらすでしょう。
</p>

    
<h3><a name="DM_NEW_FOR_GETCLASS">Dm: クラスオブジェクトを得るためだけにインスタンスを作成しているメソッド (DM_NEW_FOR_GETCLASS)</a></h3>


<p>
メソッドは、クラスオブジェクトを得るために、インスタンスを生成して <code>getClass</code> メソッドを呼び出しています。
クラスリテラル (<code>Foo.class</code>) を使うほうが簡単です。
</p>

    
<h3><a name="DM_NEXTINT_VIA_NEXTDOUBLE">Dm: 整数の乱数を生成するためには nextDouble メソッド ではなく nextInt メソッドを使用する (DM_NEXTINT_VIA_NEXTDOUBLE)</a></h3>


<p>
<code>java.util.Random</code> のインスタンス <code>r</code> で、<code>0</code> から <code>n-1</code> の乱数を生成したいのであれば、<code>(int)(r.nextDouble() * n)</code> ではなく <code>r.nextInt(n)</code> を使用します。
</p>
<p>
<code>nextInt</code> メソッドへの引数は整数でなければなりません。
たとえば、-99から0までの乱数を生成したいなら、<code>-r.nextInt(100)</code> を使用してください。
</p>

    
<h3><a name="DM_STRING_CTOR">Dm: 効率が悪い new String(String) コンストラクタを呼び出しているメソッド (DM_STRING_CTOR)</a></h3>


<p>
<code>new String(String)</code> コンストラクタの使用はメモリを浪費します。
そのようにして構築されたオブジェクトと パラメータとして渡された <code>String</code> は機能的に区別がつかないからです。
引数の <code>String</code> をそのまま使用してください。
</p>

    
<h3><a name="DM_STRING_TOSTRING">Dm: String の toString メソッドを呼び出しているメソッド (DM_STRING_TOSTRING)</a></h3>


<p>
<code>String.toString()</code> を呼び出すのは冗長です。<code>String</code> を使用してください。
</p>

    
<h3><a name="DM_STRING_VOID_CTOR">Dm: 効率が悪い new String() コンストラクタを呼び出しているメソッド (DM_STRING_VOID_CTOR)</a></h3>


<p>
引数がないコンストラクタを使用して、新しい <code>java.lang.String()</code> オブジェクトを作成するとメモリを浪費します。
そのようにして作成されたオブジェクトと空の文字列定数 <code>""</code> は機能的に区別がつかないからです。
Javaは、同一の文字列定数が同じ <code>String</code> オブジェクトによって表されることを保証します。
したがって、直接空の文字列定数を使用するべきです。
</p>

    
<h3><a name="HSC_HUGE_SHARED_STRING_CONSTANT">HSC: 複数のクラスファイルにわたって複製されている巨大な文字列定数 (HSC_HUGE_SHARED_STRING_CONSTANT)</a></h3>


<p>
巨大な文字列定数が複数のクラスファイルにわたって複製されています。
final フィールドが文字列定数で初期化され、Java 言語によって他のクラスからの final フィールドへのすべての参照がクラスファイルにインライン化されるからです。
</p>
<p>
JDK はこのバグを解決してサイズを1MB減らすことができました。<br>
詳細は、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6447475">JDK bug 6447475</a> を参照してください。
</p>

    
<h3><a name="IIO_INEFFICIENT_INDEX_OF">IIO: String.indexOf(String) の非効率的な使用 (IIO_INEFFICIENT_INDEX_OF)</a></h3>


<p>
このコードは、String.indexOf() に長さ1の文字列定数を渡しています。String.indexOf() の整数実装を使うほうが効率的です。
たとえば、<code>myString.indexOf(".")　の代わりに <code>myString.indexOf('.')</code> を呼び出します。</code>
</p>

    
<h3><a name="IIO_INEFFICIENT_LAST_INDEX_OF">IIO: String.lastIndexOf(String)　の非効率的な使用 (IIO_INEFFICIENT_LAST_INDEX_OF)</a></h3>


<p>
このコードは、String.lastIndexOf() に長さ1の文字列定数を渡しています。String.lastIndexOf() の整数実装を使うほうが効率的です。
たとえば、<code>myString.lastIndexOf(".")　の代わりに <code>myString.lastIndexOf('.')</code> を呼び出します。</code>
</p>

    
<h3><a name="ITA_INEFFICIENT_TO_ARRAY">ITA: 長さが0の配列の引数で toArray メソッドを使用しているメソッド (ITA_INEFFICIENT_TO_ARRAY)</a></h3>


<p>
このメソッドは、Collection 派生クラスの </code>toArray</code> メソッドを使用して長さが0の配列の引数を渡しています。
<code>myCollection.toArray(new Foo[myCollection.size()])</code> を使用するほうがより効率的です。
渡される配列がコレクションの要素のすべてを格納できるくらいの大きさなら、データが読み込まれて、そのまま返されます。
これは、結果として返す2番目の配列 (リフレクションによって) を作成する必要を回避します。
</p>

    
<h3><a name="SBSC_USE_STRINGBUFFER_CONCATENATION">SBSC: ループの中で + を使用して文字列を連結しているメソッド (SBSC_USE_STRINGBUFFER_CONCATENATION)</a></h3>


<p>
このメソッドは、ループの中で + を使用して <code>String</code> を構築していると思われます。
各々の繰り返しにおいて、<code>String</code> は <code>StringBuffer</code>/<code>StringBuilder</code> に変換、追加され、<code>String</code> へ変換されます。
各々の繰り返しで文字列が再コピーされ、増大すると繰り返しの数で二次コストの原因になる可能性があります。
</p>
<p>
明示的に、<code>StringBuffer</code> (または J2SE 5.0の <code>StringBuilder</code>) を使うことで、より良い性能を得られるかもしれません。
</p>
<p>
たとえば、
</p>
<blockquote><pre>
// This is bad
String s = "";
for (int i = 0; i &lt; field.length; ++i) {
    s = s + field[i];
}

// This is better
StringBuffer buf = new StringBuffer();
for (int i = 0; i &lt; field.length; ++i) {
    buf.append(field[i]);
}
String s = buf.toString();
</pre></blockquote>

    
<h3><a name="SIC_INNER_SHOULD_BE_STATIC">SIC: static 内部クラスにすべき (SIC_INNER_SHOULD_BE_STATIC)</a></h3>


<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して、必要以上に長い間作成オブジェクトへの参照を存続しておくかもしれません。
できれば、クラスは static にすべきです。
</p>

    
<h3><a name="SIC_INNER_SHOULD_BE_STATIC_ANON">SIC: 名前付き static 内部クラスにリファクタリングできるかもしれない (SIC_INNER_SHOULD_BE_STATIC_ANON)</a></h3>


<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して、必要以上に長く作成オブジェクトへの参照を存続しておくかもしれません。
できれば、クラスは static 内部クラスにすべきです。
無名内部クラスは static にできないので、名前付き内部クラスにリファクタリングする必要があります。
</p>

    
<h3><a name="SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS">SIC: static 内部クラスにリファクタリングできるかもしれない (SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS)</a></h3>


<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して、必要以上に長く作成オブジェクトへの参照を存続しておくかもしれません。
できれば、クラスは static 内部クラスにすべきです。
外部オブジェクトへの参照が内部クラスのインスタンスを構築する間必要なので内部クラスのコンストラクタに外部インスタンスへの参照を渡すようにリファクタリングする必要があります。
</p>

    
<h3><a name="SS_SHOULD_BE_STATIC">SS: 読み出されないフィールド (SS_SHOULD_BE_STATIC)</a></h3>


<p>
このクラスにはコンパイル時に静的な値に初期化されるインスタンス final フィールドがあります。
static フィールドにすることを検討してください。
</p>

    
<h3><a name="UM_UNNECESSARY_MATH">UM: 定数値で Math クラスの static メソッドを呼び出しているメソッド (UM_UNNECESSARY_MATH)</a></h3>


<p>
このメソッドは、定数値で <code>java.lang.Math</code> の static メソッドを呼び出しています。
このメソッドの結果は、静的に確定している可能性があり、より高速で、ときには定数を使用するほうがより正確です。<br>
検出されるメソッドは、以下のとおりです。 
</p>
<table>
<tr>
   <th>メソッド</th> <th>パラメータ</th>
</tr>
<tr>
   <td>abs</td> <td>-any-</td>
</tr>
<tr>
   <td>acos</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>asin</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>atan</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>atan2</td> <td>0.0</td>
</tr>
<tr>
   <td>cbrt</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>ceil</td> <td>-any-</td>
</tr>
<tr>
   <td>cos</td> <td>0.0</td>
</tr>
<tr>
   <td>cosh</td> <td>0.0</td>
</tr>
<tr>
   <td>exp</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>expm1</td> <td>0.0</td>
</tr>
<tr>
   <td>floor</td> <td>-any-</td>
</tr>
<tr>
   <td>log</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>log10</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>rint</td> <td>-any-</td>
</tr>
<tr>
   <td>round</td> <td>-any-</td>
</tr>
<tr>
   <td>sin</td> <td>0.0</td>
</tr>
<tr>
   <td>sinh</td> <td>0.0</td>
</tr>
<tr>
   <td>sqrt</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>tan</td> <td>0.0</td>
</tr>
<tr>
   <td>tanh</td> <td>0.0</td>
</tr>
<tr>
   <td>toDegrees</td> <td>0.0 or 1.0</td>
</tr>
<tr>
   <td>toRadians</td> <td>0.0</td>
</tr>
</table>

    
<h3><a name="UPM_UNCALLED_PRIVATE_METHOD">UPM: private メソッドは決して呼び出されない (UPM_UNCALLED_PRIVATE_METHOD)</a></h3>


<p>
この private メソッドは、決して呼び出されません。
メソッドがリフレクションによって呼び出されるかもしれないが、決して使われないなら除去するべきです。
</p>

    
<h3><a name="URF_UNREAD_FIELD">UrF: 読み出されないフィールド (URF_UNREAD_FIELD)</a></h3>


<p>
このフィールドは決して読み出されません。クラスから除去することを検討してください。
</p>

    
<h3><a name="UUF_UNUSED_FIELD">UuF: 未使用のフィールド (UUF_UNUSED_FIELD)</a></h3>


<p>
このフィールドは決して使われません。クラスから除去することを検討してください。
</p>

    
<h3><a name="WMI_WRONG_MAP_ITERATOR">WMI: entrySet イテレータではなく効率が悪い keySet イテレータを使用している (WMI_WRONG_MAP_ITERATOR)</a></h3>


<p>
このメソッドは、keySet イテレータから取り出されたキーを使用して、マップエントリの値にアクセスしています。
Map の entrySet イテレータを使用したほうが <code>Map.get(key)</code> ルックアップを回避するのでより効率的です。
</p>

    
<h3><a name="DMI_CONSTANT_DB_PASSWORD">Dm: ハードコードされた定数データベースパスワード (DMI_CONSTANT_DB_PASSWORD)</a></h3>


<p>
このコードは、ハードコードされた定数パスワードを使用してデータベース接続を作成しています。
ソースコードかコンパイルされたコードへアクセスできる人なら誰でも簡単にパスワードを知ることができてしまいます。
</p>

    
<h3><a name="DMI_EMPTY_DB_PASSWORD">Dm: 空のデータベースパスワード (DMI_EMPTY_DB_PASSWORD)</a></h3>


<p>
このコードは、空白または空のパスワードを使用してデータベース接続を作成しています。
これはデータベースがパスワードによって保護されていないことを示しています。
</p>

    
<h3><a name="HRS_REQUEST_PARAMETER_TO_COOKIE">HRS: 信頼できない入力から形成された HTTP cookie (HRS_REQUEST_PARAMETER_TO_COOKIE)</a></h3>


<p>
このコードは信頼できない HTTP パラメータを使用して HTTP クッキーを構築しています。
このクッキーが HTTP レスポンスに追加されるなら、HRS(HTTP レスポンススプリッティング) 脆弱性を可能にします。<br>
詳細は、<a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> を参照してください。
</p>
<p>
FindBugs は、HRS の最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。
HRS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。
</p>

    
<h3><a name="HRS_REQUEST_PARAMETER_TO_HTTP_HEADER">HRS: HTTP レスポンススプリッティング脆弱性 (HRS_REQUEST_PARAMETER_TO_HTTP_HEADER)</a></h3>


<p>
このコードは、HTTP ヘッダに HTTP パラメータを直接書き込んでいます。これは HRS(HTTP レスポンススプリッティング) 脆弱性を可能にします。<br>
詳細は、<a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> を参照してください。
</p>
<p>
FindBugs は、HRS の最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。
HRS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。
</p>

    
<h3><a name="PT_ABSOLUTE_PATH_TRAVERSAL">PT: サーブレットの絶対パストラバーサル (PT_ABSOLUTE_PATH_TRAVERSAL)</a></h3>


<p>
ソフトウェアは、制限されたディレクトリ内にあるべきパス名を構築するためにHTTPリクエストのパラメータを使いますが、パラメータはそのディレクトリの外にある場所に解決できる「/abs/path」のような絶対パスシーケンスを適切に無効にしていません。
詳細は、<a href="http://cwe.mitre.org/data/definitions/36.html">http://cwe.mitre.org/data/definitions/36.html</a> を参照してください。
</p>
<p>
FindBugs は、相対パストラバーサルの最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。
相対パストラバーサルを心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。
</p>

    
<h3><a name="PT_RELATIVE_PATH_TRAVERSAL">PT: サーブレットの相対パストラバーサル (PT_RELATIVE_PATH_TRAVERSAL)</a></h3>


<p>
ソフトウェアは、制限されたディレクトリ内にあるべきパス名を構築するためにHTTPリクエストのパラメータを使いますが、パラメータはそのディレクトリの外にある場所に解決できる「..」のようなシーケンスを適切に無効にしていません。
詳細は、<a href="http://cwe.mitre.org/data/definitions/23.html">http://cwe.mitre.org/data/definitions/23.html</a> を参照してください。
</p>
<p>
FindBugs は、相対パストラバーサルの最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。
相対パストラバーサルを心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。
</p>

    
<h3><a name="SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE">SQL: SQL の Statement の  execute メソッドに定数でない文字列を渡している (SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE)</a></h3>


<p>
このメソッドは、動的に生成されるように思われる文字列で、 SQL の <code>Statement</code> の <code>execute</code> メソッドを呼び出しています。
その代わりに <code>PreparedStatement</code> を使うことを検討してください。
効率的で、SQL インジェクション攻撃に強いです。
</p>

    
<h3><a name="SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING">SQL: PreparedStatement が定数でない文字列から生成されている (SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING)</a></h3>


<p>
このコードは、定数でない文字列から SQL の <code>PreparedStatement</code> を作成しています。
ユーザからのチェックされていない汚染されたデータがこの文字列を作る際に使われるなら、PreparedStatement で予想外で望ましくない何かをするために SQL インジェクションが使われる可能性があります。
</p>

    
<h3><a name="XSS_REQUEST_PARAMETER_TO_JSP_WRITER">XSS: 反射型クロスサイトスクリプティング脆弱性がある JSP (XSS_REQUEST_PARAMETER_TO_JSP_WRITER)</a></h3>


<p>
このコードは、JSP の出力に HTTP パラメータを直接書き込んでいます。これは XSS(クロスサイトスクリプティング) 脆弱性を可能にします。<br>
詳細は、<a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> を参照してください。
</p>
<p>
FindBugs は、XSS の最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。
XSS に関して心配しているなら商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。
</p>

    
<h3><a name="XSS_REQUEST_PARAMETER_TO_SEND_ERROR">XSS: 反射型クロスサイトスクリプティング脆弱性がエラーページにあるサーブレット (XSS_REQUEST_PARAMETER_TO_SEND_ERROR)</a></h3>


<p>
このコードは、サーブレットのエラーページに <code>HttpServletResponse.sendError</code> を使用して HTTP パラメータを直接書き込んでいます。
信頼できない入力を返すことは反射型 XSS(クロスサイトスクリプティング) 脆弱性を可能にします。<br>
詳細は、<a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> を参照してください。
</p>
<p>
FindBugs は、XSS の最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。
XSS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。
</p>

    
<h3><a name="XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER">XSS: 反射型クロスサイトスクリプティング脆弱性があるサーブレット (XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER)</a></h3>


<p>
このコードは、サーブレットの出力に HTTP パラメータを直接書き込んでいます。これは反射型 XSS(クロスサイトスクリプティング) 脆弱性を可能にします。<br>
詳細は、<a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> を参照してください。
</p>
<p>
FindBugs は、XSS の最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。
XSS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。
</p>

    
<h3><a name="BC_BAD_CAST_TO_ABSTRACT_COLLECTION">BC: 抽象コレクションへの疑わしいキャスト (BC_BAD_CAST_TO_ABSTRACT_COLLECTION)</a></h3>


<p>
このコードは、Collection を抽象コレクションにキャストしています (たとえば <code>List</code>、<code>Set</code>、<code>Map</code>)。
オブジェクトがキャストする型であると保証されることを確認してください。
必要とするコレクションの反復処理ができるなら Set または List にキャストする必要はありません。
</p>

    
<h3><a name="BC_BAD_CAST_TO_CONCRETE_COLLECTION">BC: 具象コレクションへの疑わしいキャスト (BC_BAD_CAST_TO_CONCRETE_COLLECTION)</a></h3>


<p>
このコードは抽象コレクション (たとえば、Collection、List、Set) を特定の具象実装 (たとえば、ArrayList、HashSet) にキャストしています。
これは正しくないかもしれません。そして、将来の時点で他の具象実装への切り替えをとても困難にするので、脆弱なコードになるかもしれません。
そうするために特別な理由がないかぎり抽象コレクションクラスを使用してください。
</p>

    
<h3><a name="BC_UNCONFIRMED_CAST">BC: 未チェック/未確認のキャスト (BC_UNCONFIRMED_CAST)</a></h3>


<p>
このキャストはチェックされていません。すべての型のインスタンスがキャストした型にキャストできるというわけではありません。
プログラムのロジックがこのキャストが失敗しないことを確実に確認してください。  
</p>

    
<h3><a name="BC_UNCONFIRMED_CAST_OF_RETURN_VALUE">BC: メソッドからの戻り値の未チェック/未確認のキャスト (BC_UNCONFIRMED_CAST_OF_RETURN_VALUE)</a></h3>


<p>
このコードは、メソッドの戻り値の未確認のキャストを実行しています。
コードは、キャストが安全であることが保証されるようにメソッドを呼び出しているかもしれませんが、FindBugs はキャストが安全であることを検証できません。
プログラムのロジックがこのキャストが失敗しないことを確実に確認してください。 
</p>

    
<h3><a name="BC_VACUOUS_INSTANCEOF">BC: 常に true を返す instanceof (BC_VACUOUS_INSTANCEOF)</a></h3>


<p>
この instanceof は常に true を返します (テストしている値が null でないかぎり)。
これは安全で、誤解や論理エラーを指摘していないことを確認してください。
本当に null なのか値をテストしたいなら、多分、instanceof ではなく null テストをしたほうが良く、より明確になります。
</p>

    
<h3><a name="ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">BSHIFT: 符号なし右シフトを short/byte にキャストしている (ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT)</a></h3>


<p>
このコードは、符号なしキャストの実行結果を short または byte にキャストしています。結果の上位ビットは捨てられます。
上位ビットが捨てられるので、符号付き、符号なし右シフトの (シフトのサイズによって) 違いがないかもしれません。
</p>

    
<h3><a name="CI_CONFUSED_INHERITANCE">CI: final なクラスが protected フィールドを宣言している (CI_CONFUSED_INHERITANCE)</a></h3>


<p>
このクラスは、final と宣言されていますが、フィールドは protected と宣言されています。
クラスは fainal なので派生できません。、protected の使用は紛らわしいです。 
フィールドのためのアクセス修飾子は、フィールドの真の用途を表すため、 private か public に変更するべきです。
</p>

    
<h3><a name="DB_DUPLICATE_BRANCHES">DB: 2つの分岐のために同じコードを使用しているメソッド (DB_DUPLICATE_BRANCHES)</a></h3>


<p>
このメソッドは、条件分岐の2つの分岐を実装するために同じコードを使用しています。これがコーディングミスではないことを確認してください。
</p>

    
<h3><a name="DB_DUPLICATE_SWITCH_CLAUSES">DB: switch 文の2つの case のために同じコードを使用しているメソッド (DB_DUPLICATE_SWITCH_CLAUSES)</a></h3>


<p>
このメソッドは、switch 文の2つの case を実装するために同じコードを使用しています。
複製コードの case かもしれないしコーディングミスかもしれません。
</p>

    
<h3><a name="DLS_DEAD_LOCAL_STORE">DLS: ローカル変数への無効な代入 (DLS_DEAD_LOCAL_STORE)</a></h3>


<p>
この命令はローカル変数に値を代入していますが、値は読み出されないか以降の命令でも使われません。
多くの場合、計算された値が決して使われないので、これは誤りを示します。
</p>
<p>
Sun の javac コンパイラが final なローカル変数のためにしばしば無効な格納を生成することに注意してください。
FindBugs は、バイトコードベースのツールなので誤検出をなくす簡単な方法がありません。 
</p>

    
<h3><a name="DLS_DEAD_LOCAL_STORE_IN_RETURN">DLS: return 文に役に立たない代入がある (DLS_DEAD_LOCAL_STORE_IN_RETURN)</a></h3>


<p>
この文は、return 文でローカル変数に代入をしています。この代入は効果がありません。
この文が正しいことを確かめてください。
</p>

    
<h3><a name="DLS_DEAD_LOCAL_STORE_OF_NULL">DLS: ローカル変数への無効な null 代入 (DLS_DEAD_LOCAL_STORE_OF_NULL)</a></h3>


<p>
このコードはローカル変数に null を代入していますが代入された値は読み出されていません。
この代入はガベージコレクタを手伝うために導入されたのかもしれませんが、Java SE 6 ではもはや必要とされないか有効ではありません。
</p>

    
<h3><a name="DLS_DEAD_LOCAL_STORE_SHADOWS_FIELD">DLS: フィールドを遮るローカル変数への無効な代入 (DLS_DEAD_LOCAL_STORE_SHADOWS_FIELD)</a></h3>


<p>
この命令は、ローカル変数に値を代入していますが、値は読み出されないか以降の命令でも使われません。
多くの場合、計算された値が決して使われないので、これは誤りを示します。
フィールドがローカル変数と同じ名前です。そうではなく、フィールドに代入するつもりでしたか？
</p>

    
<h3><a name="DMI_HARDCODED_ABSOLUTE_FILENAME">DMI: ハードコードされた絶対パス名への参照がある (DMI_HARDCODED_ABSOLUTE_FILENAME)</a></h3>


<p>
このコードは、ハードコードされた絶対パス名を使用して File オブジェクトを構築しています (たとえば <code>new File("/home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment");</code>)。
</p>

    
<h3><a name="DMI_NONSERIALIZABLE_OBJECT_WRITTEN">DMI: ObjectOutput に書き込まれる非直列化可能オブジェクト (DMI_NONSERIALIZABLE_OBJECT_WRITTEN)</a></h3>


<p>
このコードは、<code>ObjectOutput.writeObject</code> に非直列化可能オブジェクトを渡していると思われます。
このオブジェクトが本当に非直列化可能なら、エラーを招きます。
</p>

    
<h3><a name="DMI_USELESS_SUBSTRING">DMI: substring(0) の呼び出しは元の値を返す (DMI_USELESS_SUBSTRING)</a></h3>


<p>
このコードは、文字列で <code>substring(0)</code> を呼び出していますが、元の値を返します。
</p>

    
<h3><a name="DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">Dm: Thread オブジェクトが Runnable が期待されているところに渡されている (DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED)</a></h3>


<p>
Threadオブジェクトが Runnable が期待されているメソッドへのパラメータとして渡されています。
これはかなり異常で、論理エラーを示すか、予想外の振る舞いの原因になるかもしれません。
</p>

    
<h3><a name="EQ_DOESNT_OVERRIDE_EQUALS">Eq: スーパークラスの equals メソッドをオーバーライドしていないクラス (EQ_DOESNT_OVERRIDE_EQUALS)</a></h3>


<p>
このクラスは、<code>equals</code> メソッドを定義しているクラスを拡張してフィールドを追加していますが、<code>equals</code> メソッドを定義していません。
したがって、このクラスのインスタンスの等価性は、サブクラスと追加されたフィールドの同一性を無視します。
これが意図したことで、しかも、<code>equals</code> メソッドをオーバーライドする必要がないことを確実にしてください。
たとえ <code>equals</code> メソッドをオーバーライドする必要がないとしても、サブクラスのための <code>equals</code> メソッドが <code>super.equals(o)</code> を呼び出して結果を返すという事実を実証するために、いずれにしろ、<code>equals</code> メソッドをオーバーライドすることを検討してください。
</p>

    
<h3><a name="EQ_UNUSUAL">Eq: 異常な equals メソッド  (EQ_UNUSUAL)</a></h3>


<p>
このクラスの <code>equals</code> メソッドは、引数の型が <code>this</code> オブジェクトの型と互換性があるこをチェックするために、我々が認識しているパターンで何もしていません。
このコードは何も間違っていないかもしれませんが、レビューする価値があります。
</p>

    
<h3><a name="FE_FLOATING_POINT_EQUALITY">FE: 浮動小数点の等価性のためのテスト (FE_FLOATING_POINT_EQUALITY)</a></h3>


<p>
この演算は、等価性のために2つの浮動小数点値を比較しています。
浮動小数点の計算は丸めを伴うかもしれないので計算された float と double の値は正確ではないかもしれません。
通貨のような正確でなければならない値のために、<code>BigDecimal</code> のような固定精度型を使うことを検討してください。
正確である必要がない値のためにいくつかの範囲の中で等価性のために比較することを検討してください。
たとえば、<code>if (Math.abs(x - y) &lt; .0000001)</code>。<br>
詳細は Java 言語仕様4.2.4を参照してください。
</p>

    
<h3><a name="VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN">FS: Boolean 型でない引数を ％b 書式指示子を使用してフォーマットしている (VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN)</a></h3>


<p>
Boolean 型でない引数を %b 書式指示子でフォーマットしています。これは例外をスローしません。
その代わりに、非  null 値では true 、null では false を出力します。
書式文字列のこの機能は奇妙で意図したことではないかもしれません。
</p>

    
<h3><a name="IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">IA: 潜在的な継承されたメソッドなのか外部のメソッドなのかあいまいなメソッドの呼び出し (IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD)</a></h3>


<p>
内部クラスは、継承されたメソッドか外部クラスで定義されたメソッドなのかどちらとも解釈できるメソッドを呼び出しています。
たとえば、<code>foo(17)</code> を呼び出します。それはスーパークラスと外部のメソッドの両方で定義されています。
Java のセマンティックスでは、継承したメソッドを呼び出しますが、これは意図したことではないかもしれません。
</p>
<p>
本当に継承されたメソッドを呼び出すつもりなら super を付けて (例：super.foo(17)) 呼び出してください。
そうすれば、外部クラスのメソッドではなく継承されたメソッドを呼び出したいことがこのコードを読む人と FindBugs に明確になります。
</p>
<p>
<code>this.foo(17)</code> を呼び出す場合は、継承されたメソッドが呼び出されます。
しかしながら、FindBugs はクラスファイルを見るだけなので、<code>this.foo(17)</code> と <code>foo(17)</code> の呼び出しの違いを見分けることができません。
潜在的なあいまいな呼び出しについて文句を言うでしょう。
</p>

    
<h3><a name="IC_INIT_CIRCULARITY">IC: 初期化が循環している (IC_INIT_CIRCULARITY)</a></h3>


<p>
バグインスタンスによって参照される2つのクラスのスタティックイニシャライザで循環が検出されました。
多くの種類の予想外の振る舞いは、そのような循環に起因するかもしれません。
</p>

    
<h3><a name="ICAST_IDIV_CAST_TO_DOUBLE">ICAST: 整数の除算の結果を double または float にキャストしている (ICAST_IDIV_CAST_TO_DOUBLE)</a></h3>


<p>
このコードは 整数の除算の結果を double または float にキャストしています。
整数で除算をすることは、ゼロに最も近い整数値まで結果を切り捨てます。
結果が double にキャストされたという事実は、この精度が維持されるべきだったことを示唆しています。
おそらく意味されたことは、除算を実行する前にオペランドの1つまたは両方を double にキャストすることでした。<br>
以下に例を示します。 
</p>
<blockquote><pre>
int x = 2;
int y = 5;
// Wrong: yields result 0.0
double value1 =  x / y;

// Right: yields result 0.4
double value2 =  x / (double) y;
</pre></blockquote>

    
<h3><a name="ICAST_INTEGER_MULTIPLY_CAST_TO_LONG">ICAST: 整数乗算の結果を long にキャストしている (ICAST_INTEGER_MULTIPLY_CAST_TO_LONG)</a></h3>


<p>
このコードは、以下のように整数の乗算を実行してから結果を long に変換しています。
</p>
<blockquote><pre>
long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; } 
</pre></blockquote>
<p>
long を使用して乗算をすれば、結果がオーバーフローするという可能性を回避できます。<br>
たとえば以下のように修正できます。
</p>
<blockquote><pre>
long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; } 
</pre></blockquote>
<p>
または
</p>
<blockquote><pre>
static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; } 
</pre></blockquote>

    
<h3><a name="IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">IM: 平均の計算はオーバーフローする可能性がある (IM_AVERAGE_COMPUTATION_COULD_OVERFLOW)</a></h3>


<p>
このコードは、除算か符号付き右シフトを使用して2つの整数の平均を計算して、結果を配列の添字として使用しています。
平均値が非常に大きいならオーバーフローする可能性があります (結果として負の平均の計算になる)。
結果が負でないことを意図していたなら、その代わりに符号なし右シフトを使用できます。
つまり、<code>(low+high)/2</code> ではなく <code>(low+high) &gt;&gt;&gt; 1</code> を使用してください。
</p>
<p>
このバグは、二分探索とマージソートの多くの以前の実装で存在します。
Martin Buchholz が <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6412541">JDK ライブラリでバグを発見し、修正しています</a>。
Joshua Bloch が <a href="http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html">バグパターンとして公表しました</a>。
</p>

    
<h3><a name="IM_BAD_CHECK_FOR_ODD">IM: 負数で機能しない奇数チェック (IM_BAD_CHECK_FOR_ODD)</a></h3>


<p>
このコードは、<code>x % 2 == 1</code> を使用して値が負数なのか確かめていますが、負数 (たとえば、<code>(-5) % 2 == -1</code>) なので機能しません。
奇数チェックを意図しているなら、<code>x &amp; 1 == 1</code> または <code>x % 2 != 0</code> を使うことを検討してください。
</p>

    
<h3><a name="INT_BAD_REM_BY_1">INT: 1を法とする整数の剰余 (INT_BAD_REM_BY_1)</a></h3>


<p>
どんな式 <code>(exp % 1)</code> も常に0を返すことが保証されています。
そうではなく、<code>(exp &amp; 1)</code> または <code>(exp &amp; 2)</code> を意味していましたか？
</p>

    
<h3><a name="INT_VACUOUS_BIT_OPERATION">INT: 整数値の無意味なビットマスク演算 (INT_VACUOUS_BIT_OPERATION)</a></h3>


<p>
これはどんな有効な働きもしない整数ビット演算 (AND、OR、XOR) です (たとえば <code>v & 0xffffffff</code>)。
</p>

    
<h3><a name="INT_VACUOUS_COMPARISON">INT: 整数値の無意味な比較 (INT_VACUOUS_COMPARISON)</a></h3>


<p>
常に同じ値を返す整数の比較があります (たとえば <code>x &lt;= Integer.MAX_VALUE</code>)。 
</p>

    
<h3><a name="MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">MTIA: Servlet クラスを拡張したクラスでのインスタンス変数の使用 (MTIA_SUSPECT_SERVLET_INSTANCE_FIELD)</a></h3>


<p>
Servletクラスを拡張したクラスで、インスタンス変数を使用しています。
Servlet クラスの1つのインスタンスだけが Java EE フレームワークによって作成され、マルチスレッドによって使われるので、このパラダイムは極めて問題があり、推奨できません。
ローカル変数を使うことだけを検討してください。
</p>

    
<h3><a name="MTIA_SUSPECT_STRUTS_INSTANCE_FIELD">MTIA: Struts Action を拡張したクラスでのインスタンス変数の使用 (MTIA_SUSPECT_STRUTS_INSTANCE_FIELD)</a></h3>


<p>
Struts Action クラスを拡張したクラスで、インスタンス変数を使用しています。
Struts Action クラスの1つのインスタンスだけが Struts フレームワークによって作成され、マルチスレッドによって使われるので、このパラダイムは極めて問題があり、推奨できません。
ローカル変数を使うことだけを検討してください。
モニタを除いて書き込まれるインスタンスフィールドだけが報告されます。
</p>

    
<h3><a name="NP_DEREFERENCE_OF_READLINE_VALUE">NP: readLine メソッドの結果が null なのか確かめないで値を利用している (NP_DEREFERENCE_OF_READLINE_VALUE)</a></h3>


<p>
<code>readLine</code> メソッドの結果が null なのか確かめないで値を利用しています。
<code>readLine</code> メソッドは、それ以上読み出すテキスト行がなければ null を返すので、NullPointerException が発生します。
</p>

    
<h3><a name="NP_IMMEDIATE_DEREFERENCE_OF_READLINE">NP: readLine メソッドの結果をすぐに利用している (NP_IMMEDIATE_DEREFERENCE_OF_READLINE)</a></h3>


<p>
<code>readLine</code> メソッドの結果をすぐに利用しています。
<code>readLine</code> メソッドは、それ以上読み出すテキスト行がなければ null を返すので、NullPointerException が発生します。
</p>

    
<h3><a name="NP_LOAD_OF_KNOWN_NULL_VALUE">NP: null とわかっている値のロード (NP_LOAD_OF_KNOWN_NULL_VALUE)</a></h3>


<p>
ここで参照されている変数は、以前に null なのかチェックしているため  null であることがわかっています。
これは有効かもしれないが、間違いかもしれません (多分異なる変数を参照することを意図してました、あるいは以前の null チェックで  null でないのか確かめるべきでした)。
</p>

    
<h3><a name="NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION">NP: メソッドはパラメータに nullness アノテーションを強化している (NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION)</a></h3>


<p>
メソッドは、オーバーライドするメソッドの契約を常に実装するべきです。
したがって、メソッドが @Nullable としてマークされるパラメーターを取るならば、サブクラスでパラメーターを @Nonnull にしてメソッドをオーバーライドするべきでありません。
そうするとメソッドが null パラメータを処理すべき契約を破ります。
</p>

      
<h3><a name="NP_METHOD_RETURN_RELAXING_ANNOTATION">NP: メソッドは戻り値の nullness アノテーションを緩和している (NP_METHOD_RETURN_RELAXING_ANNOTATION)</a></h3>


<p>
メソッドは、オーバーライドするメソッドの契約を常に実装するべきです。
したがって、メソッドが @Nonnull 値を返すようにアノテートしているならば、サブクラスでメソッドが  @Nullable または @CheckForNull 値を返すようにアノテートしてメソッドをオーバーライドするべきでありません。
そうするとメソッドが null を返すべできではない契約を破ります。
</p>

      
<h3><a name="NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE">NP: null になっている可能性があるメソッドの戻り値を利用している (NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE)</a></h3>


<p>
メソッドからの戻り値を null チェックしないで利用しています。メソッドの戻り値は null なのかチェックするべきです。
コードが実行されると NullPointerException が発生するかもしれません。
</p>

    
<h3><a name="NP_NULL_ON_SOME_PATH_MIGHT_BE_INFEASIBLE">NP: null 値を実行不可能かもしれない分岐で利用している可能性がある (NP_NULL_ON_SOME_PATH_MIGHT_BE_INFEASIBLE)</a></h3>


<p>
分岐または文が実行されるなら、null 値が利用されて NullPointerException が発生します。
もちろん、問題は分岐または文が実行不可能で、NullPointerException が決して発生する可能性がないということかもしれません。
それを決めるのは FindBugs の能力を超えています。
この値がすでに null であることを検査したという事実からこれは明確な可能性です。
</p>

    
<h3><a name="NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE">NP: パラメータは  非 null でなければならないが null 可能としてアノテートされている (NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE)</a></h3>


<p>
このパラメータは、常に 非 null にすることを要求する方法で使われていますが、パラメータには明示的に null 可能としてアノテートされています。
パラメータかアノテーションのどちらかの使い方が間違っています。
</p>

    
<h3><a name="NP_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">NP: 書き込まれていない public または protected フィールドの読み出し (NP_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD)</a></h3>


<p>
プログラムは、決して null 値でない値を書き込むと思われない public または protected フィールドの null 値を利用しています。
フィールドが解析によって見られない機構を通して初期化されないかぎり、この値を利用すると NullPointerException が発生します。
</p>

    
<h3><a name="NS_DANGEROUS_NON_SHORT_CIRCUIT">NS: 潜在的な非短絡論理の危険な使用 (NS_DANGEROUS_NON_SHORT_CIRCUIT)</a></h3>


<p>
このコードは、短絡論理 (&amp;&amp; や ||) ではなく非短絡論理 (&amp; や |) を使用していると思われます。
さらに、左辺値によって右辺を評価したくない (例外のスローや演算が高くつく副作用があるため) と思っているのかもしれません。
非短絡論理は、左辺の結果がわかっていて推論できるときでも、両側の式が評価されます。
これは効率が悪く、右辺の評価でエラーが発生するケースを左辺でガードしているなら、結果としてエラーになる可能性があります。
</p>
<p>
詳細については、<a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java Language Specification</a> を参照してください。
</p>

    
<h3><a name="NS_NON_SHORT_CIRCUIT">NS: 非短絡論理の疑わしい使用 (NS_NON_SHORT_CIRCUIT)</a></h3>


<p>
このコードは、短絡論理 (&amp;&amp; や ||) ではなく非短絡論理 (&amp; や |) を使用していると思われます。
非短絡論理は、左辺の結果がわかっていて推論できるときでも、両側の式が評価されます。
これは効率が悪く、右辺の評価でエラーが発生するケースを左辺でガードしているなら、結果としてエラーになる可能性があります。
</p>
<p>
詳細については、<a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.2">the Java Language Specification</a> を参照してください。
</p>

    
<h3><a name="PZLA_PREFER_ZERO_LENGTH_ARRAYS">PZLA: null ではなく長さが0の配列を返すことを検討する (PZLA_PREFER_ZERO_LENGTH_ARRAYS)</a></h3>


<p>
結果がないこと  (すなわち、結果の空のリスト) を示すために null 参照ではなく長さが0の配列 を返すことは、多くの場合より良い設計です。
</p>
<p>
他方では、「この質問に対する答えがない」ことを示すために、null を使うことはおそらく適切です。
たとえば、<code>File.listFiles()</code> は、ファイルがないディレクトリを与えられた場合は空のリストを返し、ファイルがディレクトリでないなら null を返します。
</p>

    
<h3><a name="QF_QUESTIONABLE_FOR_LOOP">QF: 複雑か巧妙か間違ったインクリメントの for ループ (QF_QUESTIONABLE_FOR_LOOP)</a></h3>


<p>
本当にこの for ループが正しい変数をインクリメントしていますか？
別の変数が for ループによって初期化されてチェックされるように見えます。 
</p>

    
<h3><a name="RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE">RCN: 非 null 値と null 値との冗長な比較 (RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE)</a></h3>


<p>
このメソッドにはnull でないことがわかっている参照と null とわかっている別の参照との比較があります。
</p>

    
<h3><a name="RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">RCN: 2つの null 値の冗長な比較 (RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES)</a></h3>


<p>
このメソッドには両方とも明らかに null とわかっている2つの参照の冗長な比較があります。
</p>

    
<h3><a name="RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE">RCN: null でないことがわかっている値の冗長な null チェック (RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE)</a></h3>


<p>
このメソッドには null でないことがわかっている値の冗長な null チェックがあります。
</p>

    
<h3><a name="RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE">RCN: null とわかっている値の冗長な null チェック (RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE)</a></h3>


<p>
このメソッドにはnull とわかっている値の冗長な null チェックがあります。
</p>

    
<h3><a name="REC_CATCH_EXCEPTION">REC: 例外がスローされないのに例外をキャッチしている (REC_CATCH_EXCEPTION)</a></h3>


<p>
このメソッドは、例外オブジェクトをキャッチする try-catch ブロックを使用していますが、例外は try ブロックの中でスローされません。また、実行時例外は明示的にキャッチされません。
それぞれの catch ブロックが同一である多くの例外型をキャッチすることの短縮形として <code>try { ... } catch (Exception e) { something }</code> を使用することが共通のバグパターンです。
しかし、この構文は誤って実行時例外も同様にキャッチするので、潜在的なバグを隠します。
</p>
<p>
より良いアプローチは、明示的にキャッチするよりもスローされる特定の例外をスローします。
あるいは、以下に示すように明示的に RuntimeException をキャッチ、再スローして、非実行時例外をキャッチします。
</p>
<blockquote><pre>
try {
    ...
} catch (RuntimeException e) {
    throw e;
} catch (Exception e) {
    ... deal with all non-runtime exceptions ...
}
</pre></blockquote>

    
<h3><a name="RI_REDUNDANT_INTERFACES">RI: スーパークラスと同じインタフェースを実装しているクラス (RI_REDUNDANT_INTERFACES)</a></h3>


<p>
このクラスは、スーパークラスによっても実装されるインタフェースを実装することを宣言しています。
スーパークラスがインタフェースを実装するので、これは冗長です。デフォルトですべてのサブクラスもこのインタフェースを実装します。
このクラスが作成されてから継承階層が変わったことを指摘するかもしれません。インタフェースの実装の所有権を考慮するべきです。
</p>
    
    
<h3><a name="RV_CHECK_FOR_POSITIVE_INDEXOF">RV: String.indexOf の結果が正かどうか確かめている (RV_CHECK_FOR_POSITIVE_INDEXOF)</a></h3>


<p>
このメソッドは <code>String.indexOf</code> を呼び出して結果が正かどうか確かめています。
結果が負かどうか確かめるほうがずっと典型的です。チェックされる部分文字列が先頭以外の場所で出現するときだけ正になります。
</p>

    
<h3><a name="RV_DONT_JUST_NULL_CHECK_READLINE">RV: readLine メソッドの結果を null でないのか確かめた後で捨てている (RV_DONT_JUST_NULL_CHECK_READLINE)</a></h3>


<p>
<code>readLine</code> メソッドの戻り値を null でないのか確かめた後で捨てています。
ほとんどすべての状況で、結果が null でないなら戻り値を使用したいでしょう。
再び <code>readLine</code> メソッドを呼び出すと異なる行が得られます。
</p>

    
<h3><a name="RV_REM_OF_HASHCODE">RV: ハッシュコードの剰余は負かもしれない (RV_REM_OF_HASHCODE)</a></h3>


<p>
このコードは、ハッシュコードを計算して別の値を法とする剰余を計算しています。
ハッシュコードが負かもしれないので、剰余演算の結果も負かもしれません。
</p>
<p>
計算結果が負ではないことを確認したいなら、コードを変更する必要があるかもしれません。
除数が2の累乗であることがわかっているなら、代わりにビット演算を使用できます (すなわち、<code>x.hashCode()%n</code> の代わりに <code>x.hashCode()&amp;(n-1)</code> を使用してください)。
これはおそらく、剰余を計算するより高速です。
除数が2の累乗であるということをわかっていないなら、剰余演算の結果の絶対値を取得してください (すなわち <code>Math.abs(x.hashCode()%n)</code>)。
</p>

    
<h3><a name="RV_REM_OF_RANDOM_INT">RV: 符号付き32ビット整数の乱数の剰余 (RV_REM_OF_RANDOM_INT)</a></h3>


<p>
このコードは符号付き整数の乱数を生成して別の値を法とする剰余を計算しています。
乱数が負かもしれないので、剰余演算の結果も負かもしれません。これが意図したことであることを確実にしてください。
その代わりに <code>Random.nextInt(int)</code> の使用を強く検討してください。
</p>

    
<h3><a name="RV_RETURN_VALUE_IGNORED_INFERRED">RV: メソッドは戻り値を無視しています、これは間違いではないですか? (RV_RETURN_VALUE_IGNORED_INFERRED)</a></h3>


<p>
このコードは、メソッドを呼び出して、戻り値を無視しています。
戻り値は、メソッドが呼び出される型と同じ型です。そして、我々の解析から戻り値が重要であるかもしれないように見えます （たとえば、<code>String.toLowerCase()</code> の戻り値を無視するような）。 
</p>
<p>
我々は、戻り値を無視することがメソッド本体の単純な解析から悪い考えかもしれないと推測しています。
このメソッドの戻り値を無視することが重要であるか許容できるかどうかに関して、FindBugs に指示する @CheckReturnValue アノテーションが使えます。
</p>
<p>
戻り値を無視することが間違いではないか決めるために、厳密に調査してください。
</p>

    
<h3><a name="SA_FIELD_DOUBLE_ASSIGNMENT">SA: フィールドの二重代入 (SA_FIELD_DOUBLE_ASSIGNMENT)</a></h3>


<p>
このメソッドにはフィールドの二重代入があります。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
int x,y;
public void foo() {
    x = x = 17;
}
</pre></blockquote>
<p>
フィールドに2回代入することは役に立たないので、論理エラーかタイプミスかもしれません。
</p>

    
<h3><a name="SA_LOCAL_DOUBLE_ASSIGNMENT">SA: ローカル変数の二重代入 (SA_LOCAL_DOUBLE_ASSIGNMENT)</a></h3>


<p>
このメソッドにはローカル変数の二重代入があります。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
public void foo() {
    int x,y;
    x = x = 17;
}
</pre></blockquote>
<p>
変数に同じ値を2回代入することは役に立たないので、論理エラーかタイプミスかもしれません。
</p>

    
<h3><a name="SA_LOCAL_SELF_ASSIGNMENT">SA: ローカル変数の自己代入 (SA_LOCAL_SELF_ASSIGNMENT)</a></h3>


<p>
このメソッドにはローカル変数の自己代入があります。<br>
たとえば以下のようなコードです。
</p>
<blockquote><pre>
public void foo() {
    int x = 3;
    x = x;
}
</pre></blockquote>
<p>
そのような代入は役に立たないので、論理エラーかタイプミスかもしれません。
</p>

    
<h3><a name="SF_SWITCH_FALLTHROUGH">SF: 1つの case が次の case へと通り抜ける switch 文を発見した (SF_SWITCH_FALLTHROUGH)</a></h3>


<p>
このメソッドには1つの case が次の case へと通り抜ける switch 文があります。
通常、break か return でこの case を終わらせる必要があります。
</p>

    
<h3><a name="SF_SWITCH_NO_DEFAULT">SF: default がない switch 文を発見した (SF_SWITCH_NO_DEFAULT)</a></h3>


<p>
このメソッドにはdefault がない switch 文があります。
通常、default を用意する必要があります。
</p>
<p>
解析は生成されたバイトコードを見るだけなので、default が  switch 文の終わりにあって、break 文で終わらないならば、誤警告のトリガーとなります。
</p>

    
<h3><a name="ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD">ST: インスタンスメソッドから static フィールドへの書き込み (ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD)</a></h3>


<p>
このインスタンスメソッドは、static フィールドに書き込みをしています。
複数のインスタンスが操作されているなら、正しくさせるのは難しいです。一般的に間違ったプラクティスです。
</p>

    
<h3><a name="SE_PRIVATE_READ_RESOLVE_NOT_INHERITED">Se: サブクラスで継承できない private な readResolve メソッド (SE_PRIVATE_READ_RESOLVE_NOT_INHERITED)</a></h3>


<p>
このクラスは、private な <code>readResolve</code> メソッドを定義しています。
そのため、このメソッドはサブクラスで継承できません。
これが意図したことなら間違っていないかもしれませんが確認するためにレビューするべきです。
</p>

    
<h3><a name="SE_TRANSIENT_FIELD_OF_NONSERIALIZABLE_CLASS">Se: Serializable でないクラスの transient フィールド (SE_TRANSIENT_FIELD_OF_NONSERIALIZABLE_CLASS)</a></h3>


<p>
フィールドは、transient と宣言していますが、クラスは直列化可能ではないので、まったく効果がありません。
クラスが transient だったときの名残かもしれません、あるいは直列化機構を誤解しているのかもしれません。 
</p>

    
<h3><a name="TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK">TQ: 値は型修飾子を必要としているが、不明としてマークされている (TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK)</a></h3>


<p>
値は、常に型修飾子によって示された値であることを必要とする方法で使われています。
しかし、値はどこでその型修飾子が必要なのかわからないと述べている明示的なアノテーションがあります。
使い方かアノテーションのどちらかが間違っています。
</p>

    
<h3><a name="TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK">TQ: 値は型修飾子を必要としないが、不明としてマークされている (TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK)</a></h3>


<p>
値は、型修飾子によって示された値でないことを必要とする方法で使われています。
しかし、値はどこでその型修飾子がいるのか禁止されていのるかわからないと述べている明示的なアノテーションがあります。
使い方かアノテーションのどちらかが間違っています。
</p>

    
<h3><a name="UCF_USELESS_CONTROL_FLOW">UCF: 役に立たない制御フロー (UCF_USELESS_CONTROL_FLOW)</a></h3>


<p>
このメソッドには分岐するのかどうかに関係なく、制御フローが同じ場所へと続く、役に立たない制御フロー文があります。<br>
たとえば、これは 空の <code>if</code> 文が原因になります。
</p>
<blockquote><pre>
if (argv.length == 0) {
    // TODO: handle this case
}
</pre></blockquote>

    
<h3><a name="UCF_USELESS_CONTROL_FLOW_NEXT_LINE">UCF: 次の行へ続くだけの役に立たない制御フロー (UCF_USELESS_CONTROL_FLOW_NEXT_LINE)</a></h3>


<p>
このメソッドには分岐するのかどうかに関係なく、制御フローが同じか次の行へと続く、役に立たない制御フロー文があります。<br>
多くの場合、不注意に <code>if</code> 文の本体を空文を使用したことが原因になります。
</p>
<blockquote><pre>
if (argv.length == 1);
    System.out.println("Hello, " + argv[0]);
</pre></blockquote>

    
<h3><a name="URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD">UrF: 読み出されない public または protected フィールド (URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD)</a></h3>


<p>
このフィールドは決して読み出されません。 
フィールドは、public か protected なので、多分、それは解析の一部として見えないクラスで使用されることを意図しています。
そうでなければ、クラスから除去することを検討してください。
</p>

    
<h3><a name="UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD">UuF: 未使用の public または protected フィールド (UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD)</a></h3>


<p>
このフィールドは決して使用されません。
フィールドは、public か protected なので、多分、それは解析の一部として見えないクラスで使用されることを意図しています。
そうでなければ、クラスから除去することを検討してください。
</p>

    
<h3><a name="UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">UwF: コンストラクタで初期化されていないフィールドを null チェックなしで null 値を利用している (UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR)</a></h3>


<p>
このフィールドは、どんなコンストラクタの中でも決して初期化されません。したがって、オブジェクトが構築された後、null である可能性があります。
どこかほかで、値がロードされて、null チェックなしで null 値が利用されます。
フィールドが初期化される前に利用されると NullPointerException が発生するので、誤りか疑わしい設計かもしれません。
</p>

    
<h3><a name="UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">UwF: 書き込まてれいない public または protected フィールド (UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD)</a></h3>


<p>
この public または protected フィールドは書き込まれていません。このフィールドからの読み出しはデフォルト値を返します。
誤りをチェックしてください (フィールドは初期化するべきでしたか？)。使わないなら除去してください。
</p>

    
<h3><a name="XFB_XML_FACTORY_BYPASS">XFB: XMLインタフェースの特定の実装のインスタンスを作成しているメソッド (XFB_XML_FACTORY_BYPASS)</a></h3>


<p>
このメソッドは、XMLインタフェースの特定の実装のインスタンスを作成しています。
実装が実行時に変更できるように、これらのオブジェクトを作成するために提供されたファクトリクラスを使うことが望ましいです。<br>
詳細は、以下を参照してください。
</p>
<ul>
  <li>javax.xml.parsers.DocumentBuilderFactory</li>
  <li>javax.xml.parsers.SAXParserFactory</li>
  <li>javax.xml.transform.TransformerFactory</li>
  <li>org.w3c.dom.Document.create<i>XXXX</i></li>
</ul>

    


<hr> <p> 
<script language="JavaScript" type="text/javascript"> 
<!---//hide script from old browsers 
document.write( "Last updated "+ document.lastModified + "." ); 
//end hiding contents ---> 
</script> 
<p> Send comments to <a class="sidebar" href="mailto:findbugs@cs.umd.edu">findbugs@cs.umd.edu</a> 
<p> 
<A href="http://sourceforge.net"><IMG src="http://sourceforge.net/sflogo.php?group_id=96405&amp;type=5" width="210" height="62" border="0" alt="SourceForge.net Logo" /></A>
</td></tr></table>
</body></html>
